ross@cancol.oz (Ross Johnson) (11/17/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 experienced the same thing on a Sun running OS3.2 (for cross-reference). There's also a bug in the strtok() function in schedule.c which causes a core dump if you try to post an event to a group (`G' command). A context diff follows : *** schedule.c.dist Mon Nov 14 22:39:41 1988 --- schedule.c Mon Nov 14 22:47:06 1988 *************** *** 743,755 **** char *s1, *s2; { static char *pos; ! char *p, *q; if (s1 != (char *)NULL) pos = s1; ! if (*pos == '\0') ! return((char *)NULL); for (p = pos; *p != '\0'; p++) { if (index(s2, (int) *p) == (char *)NULL) --- 743,755 ---- char *s1, *s2; { static char *pos; ! char *p, *q, *index(); if (s1 != (char *)NULL) pos = s1; ! if (pos == (char *)NULL || *pos == '\0') ! return((char *)NULL); for (p = pos; *p != '\0'; p++) { if (index(s2, (int) *p) == (char *)NULL)
ross@cancol.oz (Ross Johnson) (11/17/88)
In article <115@cancol.oz>, ross@cancol.oz (Ross Johnson) writes: > In article <1252@leah.Albany.Edu>, rds95@leah.Albany.Edu (Robert Seals) writes: > > Specifically, it should go away after the user logs out, and it > > doesn't. > > > I've experienced the same thing on a Sun running OS3.2 (for cross-reference). (I think this applies to BSD systems in general but I don't know about SYS5.) This works for Sun OS3.2. Monthd knows it won't get any signal to die at logout (because monthd spawns an orphan child which gets inherited by init) so it attempts to find out at it's regular awakening if the user has logged out. For non SYS5 systems it assumes that doing a getpgrp(0) will return 0 if this is so but it isn't. Instead, I do a getpgrp(parent_pid) and look for an error return of -1. Because monthd sets parent_pid = getppid() before the fork it's the pid of the login shell - which will disappear at logout. I've removed the setpgrp() call as well. This only works if you really logout as different from using "login" (to someone else) in your current shell. The later uses the same shell process before and after (and hence the same pid) but presumably you logout eventually :-). Here's the context diff: *** monthd.c.dist Thu Nov 17 13:39:31 1988 --- monthd.c Thu Nov 17 23:10:01 1988 *************** *** 65,73 **** --- 65,75 ---- #ifdef hpux setpgrp2(0, parent_pid); #else + #ifdef SYS5 setpgrp(0, parent_pid); #endif #endif + #endif inf_loop(); } *************** *** 216,228 **** logged_out() { /* fprintf(tty, "%s: child pgrp = %d\n", prog_name, getpgrp()); */ - #if SYS5 return(getpgrp() == 0); /* pgrp is 0 after logout */ #else ! return(getpgrp(0) == 0);/* pgrp is 0 after logout */ #endif } --- 218,233 ---- logged_out() { + #if SYS5 /* fprintf(tty, "%s: child pgrp = %d\n", prog_name, getpgrp()); */ return(getpgrp() == 0); /* pgrp is 0 after logout */ #else ! /* ! fprintf(tty, "%s: -csh pgrp = %d\n", prog_name, getpgrp(parent_pid)); ! */ ! return(getpgrp(parent_pid) == -1); /* is -csh still around? */ #endif }
guy@auspex.UUCP (Guy Harris) (11/22/88)
>+ #ifdef SYS5 > setpgrp(0, parent_pid); > #endif > #endif >+ #endif "setpgrp" takes no arguments in a vanilla System V system; it establishes a brand-new process group and makes the invoking process the first member. It also detaches the process from its current controlling terminal, if it has one and it was not a process group leader when it executed "setpgrp". Of course, that has nothing to do with SunOS 3.2, since it doesn't fully support S5-style process group semantics (SunOS 4.0 supports them to the maximum extent possible, given that it also has to support 4.3BSD-style process group semantics).