rick@zeek.UUCP (Rick Wilhelm) (11/10/89)
When I run ps(1) I get the following results $ ps ps: unlink() failed ps: /etc/ps_data, Permission denied ps: Please notify your System Administrator PID TTY TIME COMMAND 6237 pts010 0:00 ksh 6825 pts010 0:10 ps $ This problem happens sporadically, with no _apparent_ causes. Anyone have any ideas? I RTFM but to no avail. System: AT&T 6386 WGS running System V/386 Release 3.2 with KornShell Version 06/03/86a 386 Release 1.1 Thanks, rick -- ------------------------------------------------------------------------------- Rick Wilhelm uunet!zeek!rick Andersen Consulting 312-715-5471 Advanced Systems Center, Chicago
cpcahil@virtech.uucp (Conor P. Cahill) (11/10/89)
In article <269@zeek.UUCP>, rick@zeek.UUCP (Rick Wilhelm) writes: > $ ps > ps: unlink() failed > ps: /etc/ps_data, Permission denied > ps: Please notify your System Administrator > PID TTY TIME COMMAND > 6237 pts010 0:00 ksh > 6825 pts010 0:10 ps > $ > > This problem happens sporadically, with no _apparent_ causes. > Anyone have any ideas? I RTFM but to no avail. ps will try to re-make /etc/ps_data whenever /etc/passwd, /unix, /etc/group (and possibly other files that I can't remember) change. In order to do this the program and /etc are usually setup as follows: -r-xr-sr-x 1 root sys 21472 May 22 15:28 /bin/ps drwxrwxr-x 20 root sys 3552 Nov 9 18:16 /etc my *guess* would be that one of these is not correct and therefore the ps cannot rebuild /etc/ps_data. However, at some point someone that does have write access to /etc does run ps which therefore correctly re-builds the /etc/ps_data file and from then on nobody has to rebuild it. another possibility is that there is a race condition in the rebuilding of the /etc/ps_data file by two simultaneous ps processes. All in all, it just doesn't matter. your ps still works correctly and eventually the file will be rebuilt correctly, so you probably can ignore the messages unless they are continuous. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
johnl@esegue.segue.boston.ma.us (John R. Levine) (11/10/89)
In article <269@zeek.UUCP> rick@zeek.UUCP (Rick Wilhelm) writes: >ps: unlink() failed >ps: /etc/ps_data, Permission denied >ps: Please notify your System Administrator The first time ps runs after a reboot, it looks up all of the kernel symbols that it needs and saves them in /etc/ps_data. (It probably does the same thing if /unix is newer than ps_data.) Thereafter it looks in the file rather than looking them up again. For this hack to work, ps needs to be able to read /unix and /dev/kmem, and to be able to write in /etc. Here are the permissions on my system that make it possible: -r-xr-sr-x 1 root sys 21472 May 8 1989 /bin/ps cr--r----- 1 sys sys 2, 1 May 8 1989 /dev/kmem drwxrwxr-x 19 root sys 3312 Nov 10 09:26 /etc Usually the problem is that /etc isn't 775 or else /etc and /bin/ps aren't in the same group. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Massachusetts has over 100,000 unlicensed drivers. -The Globe
amitc@cbnewsl.ATT.COM (amit.chatterjee) (11/11/89)
In article <269@zeek.UUCP>, rick@zeek.UUCP (Rick Wilhelm) writes: > > When I run ps(1) I get the following results > > $ ps > ps: unlink() failed > ps: /etc/ps_data, Permission denied > ps: Please notify your System Administrator > PID TTY TIME COMMAND > 6237 pts010 0:00 ksh > 6825 pts010 0:10 ps > $ > > This problem happens sporadically, with no _apparent_ causes. > Anyone have any ideas? I RTFM but to no avail. > > System: AT&T 6386 WGS running System V/386 Release 3.2 > with KornShell Version 06/03/86a 386 Release 1.1 > > Thanks, > > rick > -- The problem is actually very simple, the cause as to why this ever happens is unknown to me. Anyway, the easy stuff first. $ ls -ld /etc drwxrwxr-x 16 root sys 2736 Nov 10 14:51 /etc $ $ ls -l /bin/ps -r-xr-sr-x 1 bin sys 21788 Nov 14 1988 /bin/ps As you can see, ps has setgid to sys. It tries to unlink a file called /etc/ps_data which requires write permission on /etc. /etc has write permission for its group. This is when all is well. Now when the problem you describe happens, if you take a look at /etc's permissions, you will notice that the group ownership of /etc changes from sys to bin, like below: drwxrwxr-x 16 root bin 2736 Nov 10 14:51 /etc In this case ps cannot write in /etc and you get this error. What I would like to know from any wizard out there, what causes the group ownership to change on /etc. I have this problem once in a while on AT&T 3B2 machines running UNIX System V Rel 3.2. ======================================================================= Amit Chatterjee (201) 271-1130 AT&T CSIL {major gateway}!tarpon!amit Somerset, NJ amit@tarpon.att.com =======================================================================