Subject: Re: postgres & root

From: [email-masked] (Paul M. Aoki)
Date: Mon, 28 Mar 94 13:43:14 -0800

a system administrator writes:
> I'm the guilty party Ken Dueker at U of Oregon implied to you for running 
> postmaster under root - Postmaster fails to get shared memory allocated when
> running as postgres.  error message is IpcMemoryAttach:  shmat failed: permis
sion
> denied.

i don't know offhand, but the following can cause a problem with
the same symptoms:

> faerie:postgres (142)> whoami
> postgres
> faerie:postgres (143)> ipcs
> 
> IPC status from /dev/kmem as of Mon Mar 28 21:22:04 1994
> Message Queues:
> T     ID     KEY        MODE       OWNER    GROUP
> *** No message queues are currently defined ***
> 
> Shared Memory
> T     ID     KEY        MODE       OWNER    GROUP
> m      0          0 D-rw-------     root   system
> m      1          0 D-rw-------     root   system
> m      2          0 D-rw-------     root   system
> m    803  123585129 --rw-------     aoki postgres
> m    804  123585135 --rw-------     aoki postgres
> 
> Semaphores
> T     ID     KEY        MODE       OWNER    GROUP
> s    280  123585139 --ra-------     aoki postgres
> s    281  123585140 --ra-------     aoki postgres
> s    282  123585141 --ra-------     aoki postgres

[segments owned by aoki are left over from a dead postmaster]

> faerie:postgres (144)> postmaster
> IpcMemoryAttach: shmat() failed: Permission denied
> faerie:postgres (145)> 

that is, say someone once tried to start a postmaster on a given 
port as user <foo>, which crashed without releasing its shared 
memory segments.  if you then try to start a postmaster as user 
<bar> on the *same port*, the postmaster will try to create a 
new segment with the same key (the key is derived from the port
number).  shmget(2) says, "great, there's already a segment with 
that key, here's the shmid for it," but when the postmaster tries 
to *attach* with shmat(2), shmat says, "bogus! this segment doesn't
belong to you -- hasta luego."  (it actually says EACCES but that's
my translation into kowfornian.)

you don't get the usual "two postmasters on one port" message:

> FATAL: StreamServerPort: bind() failed: errno=13
>	Is another postmaster already running on that port?
>	If not, wait a few seconds and retry.
> postmaster: cannot create stream port

because the other postmaster is dead and not occupying the port.

(it is also possible but less likely that some other random process 
just happens to have a segment with the same shared memory key.  in 
either case, however, ipcs reveals all.)

if this is the problem, it ought to go away if you blow away the 
dead shmem segments (using ipcrm) or reboot the machine.

(to prevent a different set of problems, make sure the binaries 
aren't setuid.)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki

---

From: [email-masked] (Paul M. Aoki)
Date: Mon, 28 Mar 94 14:02:54 -0800

sion
> denied.

i should add that the usual reason for the postmaster being unable 
to free shared memory when it dies is the use of "kill -9" or "kill
-KILL".  in the 4.2 doc i tried to dissuade people from using "kill 
-9" for this reason.  just plain "kill" works fine; the postmaster 
catches the signal and frees the shared resources before calling 
exit(2).  if you use SIGKILL, it can't do that.
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki