sdb@whuxlm.UUCP (Brener Stanley) (01/28/85)
Why does: nohup ps fail to produce significant output in nohup.out under AT&T UNIX* 5.2? Only the ps header line is output. * UNIX is a trademark of AT&T Bell Laboratories.
wlb@rruxo.UUCP (B Boutin) (01/30/85)
Ah, finally one I know. nohup-ing ps losses the user information and therefore doesn't print processes for you. If you try nohup ps -u[your login], it will work! -- Bill Boutin, Bell Communications Research, Inc., 444 Hoes Lane, Room 4D-336, Piscataway, NJ, 08854 201-699-4700
guy@rlgvax.UUCP (Guy Harris) (01/31/85)
> Why does: > > nohup ps > > fail to produce significant output in nohup.out under AT&T UNIX* 5.2? > Only the ps header line is output. Because the command "ps" lists only the processes attached to the "current terminal", where the "current terminal" is the one which file descriptor 2 refers to. Since file descriptor 2 is redirected to "nohup.out" by "nohup", "ps" can't determine what the current terminal is, and so finds no processes attached to that terminal. Unfortunately, file descriptor 0 is redirected to /dev/null for background processes in the Bourne shell, so that won't work (FD1 is also redirected to "nohup.out"). Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
mike@whuxl.UUCP (BALDWIN) (02/02/85)
Actually, "nohup ps" fails because nohup redirects stdout and stderr to nohup.out, making your controlling terminal's name inaccessible. Stdin is still connected, but ps doesn't use it. "nohup cmd &" will completely detach it (except for /dev/tty). [this is on SVR2]
gam@amdahl.UUCP (gam) (02/02/85)
> Ah, finally one I know. > nohup-ing ps losses the user information and therefore doesn't > print processes for you. If you try nohup ps -u[your login], it will work! It probably will, but not because of lost user information. It is because ps(1) looks at stderr to figure out what the "controlling terminal" is; nohup redirects stderr to nohup.out, thus there is no "controlling terminal." It also does not handle this case correctly, as it blithely assumes stderr is ALWAYS a terminal. Your example gives different selection criteria (user id) and thus works; the default is to select all processes associated with the current terminal. (this was a fun problem!). -- Gordon A. Moffett ...!{ihnp4,hplabs,sun}!amdahl!gam
jas@rtech.ARPA (Jim Shankland) (02/05/85)
> ... ps(1) looks at stderr to figure out what the "controlling > terminal" is. > Gordon A. Moffett ...!{ihnp4,hplabs,sun}!amdahl!gam If this is true, it seems like a horrible hack to me. Surely ps could get its notion of the controlling terminal from the proc table entry for the ps process itself (it is, after all, already rooting around in the proc table)? The notion of a controlling terminal is an attribute of a process, and need not have any connection with what files that process has open. Anybody know whether (1) Gordon is wrong; (2) Gordon is right, and I'm right, so ps is just ugly; or (3) I've missed something? Jim Shankland ..!ucbvax!mtxinu!rtech!jas
jas@rtech.ARPA (Jim Shankland) (02/05/85)
> > ... ps(1) looks at stderr to figure out what the "controlling > > terminal" is. > > Gordon A. Moffett ...!{ihnp4,hplabs,sun}!amdahl!gam > > If this is true, it seems like a horrible hack to me. Surely ps could > get its notion of the controlling terminal from the proc table entry > for the ps process itself (it is, after all, already rooting around > in the proc table)? The notion of a controlling terminal is an attribute > of a process, and need not have any connection with what files that > process has open. > > Anybody know whether (1) Gordon is wrong; (2) Gordon is right, and I'm > right, so ps is just ugly; or (3) I've missed something? Rather than just asking, I thought I'd check, myself. First, a minor inaccuracy in my above posting: the control terminal information is stored in a process's u area, not in the proc table. However, ps looks in the u area of every process it displays, anyway. Second, ps by default does indeed display all processes whose control terminal is the same as file descriptor 2 (a.k.a. stderr). For the reasons given above, this strikes me as stupid. By the way, the source for ps would gag a goat. Also, none of this applies to the Berklix ps's. Jim Shankland ..!ucbvax!mtxinu!jas
mike@whuxl.UUCP (BALDWIN) (09/17/85)
> Actually, ``ps'' and other kernel-grubbers should generally be > setgid (not setuid) to a special group that can read the appropriate > files. But you have to be careful: most ps's let you specify which namelist, swap, and core files to open (-n,-s,-c in SV), and you don't want to open them with gid sys. Theoretically, you can munge up a fake core file or namelist that would let you read parts of sys files you shouldn't (i.e., the clists from /dev/kmem). And it's worse: if ANY of the files are user specified, don't open ANY of the files with gid sys! This could be annoying for a user wanting to use, say, /OLDunix for a namelist when an old version is booted, but again, with lots of tomfoolery you can rig up a namelist to read parts of /dev/kmem you shouldn't. > I have a question, though: is SysV's /dev/swap somehow different > from 4.xBSD's /dev/drum? If not, the suggestion given here > (approximately ``ln /dev/fuji /dev/swap'') won't work. Here (SVR2), /dev/swap has the same maj,min as /dev/dsk/0s0, so it's not a pseudo-device like /dev/drum. I don't know how the paging release uses /dev/swap. -- Michael Baldwin AT&T Bell Labs {at&t}!whuxl!mike
dave@uwvax.UUCP (Dave Cohrs) (09/19/85)
> > Actually, ``ps'' and other kernel-grubbers should generally be > > setgid (not setuid) to a special group that can read the appropriate > > files. > > But you have to be careful: most ps's let you specify which namelist, > swap, and core files to open (-n,-s,-c in SV), and you don't want to > open them with gid sys. [ more detail deleted, your news-reading program can find it, I'm sure ] The simplest way to ensure this protection is (assuming setgid=sys program): 1) open("/dev/kmem", 0) 2) open("/dev/drum", 0) /* or your favorite swap device */ 3) setgid(getgid()); 4) open("namelist", 0); ... This way, the protected files get accessed correctly, while the namelist and all following work get done as joe-user. Of course, to have extra protection, you could do a stat() on the namelist file and make sure it's owned by root or something to guarantee against bogus namelists. -- Dave Cohrs (608) 262-1204 ...!{harvard,ihnp4,seismo,topaz}!uwvax!dave dave@wisc-romano.arpa
brp@starfire.UUCP (Ben Pennington) (10/11/85)
> > > Actually, ``ps'' and other kernel-grubbers should generally be > > > setgid (not setuid) to a special group that can read the appropriate > > > files. > > > > But you have to be careful: most ps's let you specify which namelist, > > swap, and core files to open (-n,-s,-c in SV), and you don't want to > > open them with gid sys. > [ more detail deleted, your news-reading program can find it, I'm sure ] > > The simplest way to ensure this protection is (assuming setgid=sys program): > 1) open("/dev/kmem", 0) > 2) open("/dev/drum", 0) /* or your favorite swap device */ > 3) setgid(getgid()); > 4) open("namelist", 0); > > ... > > This way, the protected files get accessed correctly, while the namelist > and all following work get done as joe-user. Of course, to have extra > protection, you could do a stat() on the namelist file and make sure > it's owned by root or something to guarantee against bogus namelists. > > -- > Dave Cohrs > (608) 262-1204 > ...!{harvard,ihnp4,seismo,topaz}!uwvax!dave > dave@wisc-romano.arpa gfgoiurtoituoerut t n q ZZ *** REPLACE THIS LINE WITH YOUR MESSAGE ***