home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / programm / 4601 < prev    next >
Encoding:
Text File  |  1992-09-09  |  1.9 KB  |  45 lines
  1. Newsgroups: comp.unix.programmer
  2. Path: sparky!uunet!europa.asd.contel.com!awds.imsd.contel.com!mahendo!thyme!kaleb
  3. From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
  4. Subject: changing process groups
  5. Message-ID: <1992Sep9.231540.9783@thyme.jpl.nasa.gov>
  6. Organization: Jet Propulsion Lab, Pasadena, CA
  7. Date: Wed, 9 Sep 92 23:15:40 GMT
  8. Lines: 35
  9.  
  10. On a Sun SPARC running SunOS 4.1.1 I have two programs, one, a trivial 
  11. daemon is started from rc.local, and the other, an X application is 
  12. started from the window manager.  Both programs detach from any controlling 
  13. terminal.
  14.  
  15. I want to enlist the aid of the kernel to automatically send a signal to 
  16. the X application when the daemon is terminated.  To that end, the daemon 
  17. calls setsid() to become a session leader and a process group leader, and 
  18. stores the process group ID (pgid) it returns into shared memory.  
  19.  
  20. The X client reads that pgid from the shared memory, and calls setpgid() 
  21. to attempt to join the daemons process group.
  22.  
  23. I've read and reread TFM, as well as W. Richard Stevens latest book,
  24. "Advanced Programming in the UNIX Environment", and can find no documented
  25. reason why this shouldn't work, yet the call to setpgid() in the X appli-
  26. cation returns -1 and errno is EPERM.
  27.  
  28. This error is triggered even when both programs are SGID to the same group.
  29. Evidently the error is that the programs aren't in the same session initially.
  30.  
  31. As the daemon runs as root, it can send signals to the X application(s)
  32. directly, however when I tried that strategy, and there are many (16+) X 
  33. apps, I observe that some of them don't receive the signal.  They're all 
  34. the same program, and the daemon *is* sending the signal to all of them
  35.  
  36. Anyone have an explanation about the wherefor of any of the above?
  37.  
  38. Thanks.
  39.  
  40. -- 
  41.  
  42. Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov
  43.  
  44. Not authorized, in any way, shape, or form, to speak for anyone.
  45.