rds95@leah.Albany.Edu (Robert Seals) (11/14/88)
I brought up the recently posted "month". The program itself seems to work quite nicely, but the daemon program that checks for appointments does not. Specifically, it should go away after the user logs out, and it doesn't. I don't think it works at all, actually, cuz it hasn't been announcing my engagements, as it ought to. The system is microvax II with ultrix 1.2. I used gcc-1.28 to build. Any help, anybody? rob
louie@trantor.umd.edu (Louis A. Mamakos) (11/15/88)
In article <1252@leah.Albany.Edu> rds95@leah.Albany.Edu (Robert Seals) writes: >I brought up the recently posted "month". The program itself seems to >work quite nicely, but the daemon program that checks for appointments >does not. Specifically, it should go away after the user logs out, and it >doesn't. I don't think it works at all, actually, cuz it hasn't been >announcing my engagements, as it ought to. I've tried to use monthd on a MicroVAX-II running 4.3BSD. The problem with it not announcing events can probably be solved by adding a line like: fflush(tty); in the function which prints the message on the terminal. I also have the problem with monthd not exiting when I log out; I have not yet had the time to solve that problem. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
gandalf@csli.STANFORD.EDU (Juergen Wagner) (11/16/88)
In article <3035@haven.umd.edu> louie@trantor.umd.edu (Louis A. Mamakos) writes: >I also have the problem with monthd not exiting when I log out; I have not >yet had the time to solve that problem. I don't have the original sources of `month' around, but the problem with `monthd' sitting around even after logging out can be fixed easily by doing a kill(getppid(), 0) and checking the return value for ESRCH. I did that in the main daemon loop after the sleeping. You could also check /etc/utmp if the user is still logged in, or use a wrapper which forks the monthd, and which kills it off as soon the parent dies. Juergen Wagner wagner.pa@xerox.com -- Juergen "Gandalf" Wagner, gandalf@csli.stanford.edu Center for the Study of Language and Information (CSLI), Stanford CA
morrell@hpsal2.HP.COM (Michael Morrell) (11/16/88)
/ hpsal2:comp.sources.d / rds95@leah.Albany.Edu (Robert Seals) / 6:09 am Nov 14, 1988 /
I brought up the recently posted "month". The program itself seems to
work quite nicely, but the daemon program that checks for appointments
does not. Specifically, it should go away after the user logs out, and it
doesn't. I don't think it works at all, actually, cuz it hasn't been
announcing my engagements, as it ought to.
The system is microvax II with ultrix 1.2. I used gcc-1.28 to build.
Any help, anybody?
rob
----------
As someone else already mentioned, on systems where /dev/tty is not line
buffered by default, a "fflush(tty)" needs to be added at the end of
"print_reminder()". This will be included in an upcoming patch.
As far as the program not terminating when you log out, I'll look into that
and post an announcement when I find out something.
Thanks for all the kind words on the program.
Michael Morrell
{hplabs,ucbvax}!hpda!morrell
morrell%hpda@hplabs.hp.comjohn@stiatl.UUCP (John DeArmond) (11/17/88)
In article <6454@csli.STANFORD.EDU> wagner.pa@xerox.com (Juergen Wagner) writes: >In article <3035@haven.umd.edu> louie@trantor.umd.edu (Louis A. Mamakos) writes: >>I also have the problem with monthd not exiting when I log out; I have not >>yet had the time to solve that problem. > >I don't have the original sources of `month' around, but the problem with >`monthd' sitting around even after logging out can be fixed easily by doing >a kill(getppid(), 0) and checking the return value for ESRCH. I did that >in the main daemon loop after the sleeping. > >You could also check /etc/utmp if the user is still logged in, or use a wrapper >which forks the monthd, and which kills it off as soon the parent dies. > >Juergen Wagner >wagner.pa@xerox.com >-- >Juergen "Gandalf" Wagner, gandalf@csli.stanford.edu >Center for the Study of Language and Information (CSLI), Stanford CA I have brought the distribution version of MONTH up on our Convergent Mightyframe (sysV, rel 2), and it does in fact terminate after logoff, though not necessarily immediately. What you may be seeing is if you logoff and immediately back in, monthd is still there because it may not have awoke yet. If it awakes and the logon session is gone, it does terminate. Here's my Cshell solution to the problem. Put this in your .login file. ---------------- if (`ps | grep -c monthd` == 0) then monthd echo loading monthd endif ---------------- That way, it is only loaded if it does not already exist. I also experienced the problem of the notices not making it to the screen but the fflush(tty) fix already posted should work. I have not had time to do that though. John De Armond Sales Technologies, Inc. Atlanta, GA ...!gatech!stiatl!john
pcg@aber-cs.UUCP (Piercarlo Grandi) (11/20/88)
In article <4110001@hpsal2.HP.COM> morrell@hpsal2.HP.COM (Michael Morrell) writes:
/ hpsal2:comp.sources.d / rds95@leah.Albany.Edu (Robert Seals) / 6:09 am Nov 14, 1988 /
I brought up the recently posted "month". The program itself seems to
work quite nicely, but the daemon program that checks for appointments
does not. Specifically, it should go away after the user logs out, and it
doesn't.
As far as the program not terminating when you log out, I'll look into that
and post an announcement when I find out something.
Thanks for all the kind words on the program.
Michael Morrell
Mike, I also have kind words for the big improvement in the program. My only
gripe is that the binary format for the .month file makes it not portable
across machines, i.e. I cannot use the same file from a SUN or a VAX.
As to the logging out problem, this is because monthd MUST be the direct
offspring of the login shell, as it will attach itself to the process group of
its parent; if this parent is not the shell, it will never receive the HUP
signal on logout. In particular doing "month -d" loses badly because then
the parent of monthd is month, not the shell.
It may also be that some systems do not send a HUP signal on logging out.
For added safety, I do a "kill -HUP 0" or a "kill -TERM 0" when logging
out (either in .logout, or in its B-shell equivalent).
The suggestion (advanced in an earlier message) to see if the parent is still
around is not effective, of course.
--
Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BX (UK)tom@tnosoes.UUCP (Tom Vijlbrief) (11/21/88)
I posted a buggy fix for the not terminating monthd :-( .
return(kill(parent_pid, 0) == ESRCH);/* Parent is gone */
instead of
return(kill(parent_pid, 0) < 0 && errno == ESRCH);/* Parent is gone */
This one should work...
=================================================================
Here is a diff that fixes this problem. (Monthd not terminating).
It also sets the correct group owner on the .month file.
This is necessary for BSD systems, because files have the same group owner
as their directory when they are created. Sys-V sets the group owner to
the effective groupid.
Tom
===============================================================================
Tom Vijlbrief
TNO Institute for Perception
P.O. Box 23 Phone: +31 34 63 62 77
3769 DE Soesterberg E-mail: tnosoes!tom@mcvax.cwi.nl
The Netherlands or: uunet!mcvax!tnosoes!tom
===============================================================================
*** org/read_sched.c Mon Nov 14 11:34:55 1988
--- read_sched.c Fri Nov 18 09:29:14 1988
***************
*** 48,54 ****
if (read_mode == READ_ONLY)
fd = open(schedule_file_name, O_RDONLY);
else {
! if ((fd = open(schedule_file_name, O_RDWR|O_CREAT, 0660)) != -1)
#if LOCKF
if (lockf(fd, F_TLOCK, 0L) == -1) {
close(fd);
--- 48,55 ----
if (read_mode == READ_ONLY)
fd = open(schedule_file_name, O_RDONLY);
else {
! if ((fd = open(schedule_file_name, O_RDWR|O_CREAT, 0660)) != -1) {
! fchown(fd, -1, getegid());
#if LOCKF
if (lockf(fd, F_TLOCK, 0L) == -1) {
close(fd);
***************
*** 64,69 ****
--- 65,71 ----
}
#endif FLOCK
#endif LOCKF
+ }
}
#else
fd = open(schedule_file_name, O_RDWR|O_CREAT, 0660);
*** org/monthd.c Thu Nov 17 10:27:35 1988
--- monthd.c Thu Nov 17 16:46:16 1988
***************
*** 6,11 ****
--- 6,12 ----
#include <signal.h>
#include <sys/types.h>
#include <ctype.h>
+ #include <errno.h>
#include "month.h"
short dhour, dminute, dsecond;
***************
*** 222,228 ****
--- 223,232 ----
#if SYS5
return(getpgrp() == 0); /* pgrp is 0 after logout */
#else
+ #if 0
return(getpgrp(0) == 0);/* pgrp is 0 after logout */
+ #else
+ return(kill(parent_pid, 0) < 0 && errno == ESRCH);/* Parent is gone */
#endif
#endif
}peter@ficc.uu.net (Peter da Silva) (11/24/88)
In article <416@tnosoes.UUCP>, tom@tnosoes.UUCP (Tom Vijlbrief) writes: > I posted a buggy fix for the not terminating monthd :-( . I think you just posted another one. > return(kill(parent_pid, 0) < 0 && errno == ESRCH);/* Parent is gone */ > This one should work... Unless you kicked month off in a subshell. I would recommend basing this on the process group id (which is the process ID of your login shell) instead of your parent. I don't understand the point of all these shenanigans, anyway, since month catches that ol' signal 1 and terminates just fine. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net