Обсуждение: BUG #16067: Failed system call was semget

Поиск
Список
Период
Сортировка

BUG #16067: Failed system call was semget

От
PG Bug reporting form
Дата:
The following bug has been logged on the website:

Bug reference:      16067
Logged by:          chelsea lyu
Email address:      chelsealyu@gmail.com
PostgreSQL version: 11.5
Operating system:   MacOS
Description:

running bootstrap script ... 2019-10-19 23:25:15.095 JST [51410] FATAL:
could not create semaphores: No space left on device
2019-10-19 23:25:15.095 JST [51410] DETAIL:  Failed system call was
semget(5432226, 17, 03600).

this is the code what I input, and then the problem is out.
MacBook-Pro:~ raye$ initdb /usr/local/var/postgres -E utf8


I also tried the code in the guide book of solving this question.
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmax
kern.sysv.shmmax: 4194304
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmin
kern.sysv.shmmin: 1
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmni
kern.sysv.shmmni: 32
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmseg
kern.sysv.shmseg: 8
RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmall
kern.sysv.shmall: 1024

but nothing happened.
it still cannot work.


Re: BUG #16067: Failed system call was semget

От
Tomas Vondra
Дата:
On Sat, Oct 19, 2019 at 02:54:45PM +0000, PG Bug reporting form wrote:
>The following bug has been logged on the website:
>
>Bug reference:      16067
>Logged by:          chelsea lyu
>Email address:      chelsealyu@gmail.com
>PostgreSQL version: 11.5
>Operating system:   MacOS
>Description:
>
>running bootstrap script ... 2019-10-19 23:25:15.095 JST [51410] FATAL:
>could not create semaphores: No space left on device
>2019-10-19 23:25:15.095 JST [51410] DETAIL:  Failed system call was
>semget(5432226, 17, 03600).
>
>this is the code what I input, and then the problem is out.
>MacBook-Pro:~ raye$ initdb /usr/local/var/postgres -E utf8
>
>
>I also tried the code in the guide book of solving this question.
>RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmax
>kern.sysv.shmmax: 4194304
>RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmin
>kern.sysv.shmmin: 1
>RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmni
>kern.sysv.shmmni: 32
>RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmseg
>kern.sysv.shmseg: 8
>RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmall
>kern.sysv.shmall: 1024
>
>but nothing happened.
>it still cannot work.
>

I think you need to tweak kernel.sem, not the options for sysv shared memory.

Also, not a PostgreSQL bug, but an OS configuration issue ...


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 



Re: BUG #16067: Failed system call was semget

От
Tom Lane
Дата:
PG Bug reporting form <noreply@postgresql.org> writes:
> Operating system:   MacOS

> running bootstrap script ... 2019-10-19 23:25:15.095 JST [51410] FATAL: 
> could not create semaphores: No space left on device
> 2019-10-19 23:25:15.095 JST [51410] DETAIL:  Failed system call was
> semget(5432226, 17, 03600).

That's a bit odd.  macOS is known to have low default limits for
SysV shared memory, but not for semaphores.  Which macOS version
are you running, exactly?  What do you get from
    sysctl -a | grep sysv.sem
?  I get

kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl: 87381
kern.sysv.semume: 10

(and not only in Catalina, but very ancient mac versions)

Is it possible that something else is chewing up semaphores?
Looking at "sudo ipcs -s" output would reveal that.

> I also tried the code in the guide book of solving this question.
> RAYEdeMacBook-Pro:~ raye$ sysctl -w kern.sysv.shmmax
> kern.sysv.shmmax: 4194304

That is not about this problem.

            regards, tom lane



Re: BUG #16067: Failed system call was semget

От
Thomas Munro
Дата:
On Sun, Oct 20, 2019 at 4:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> PG Bug reporting form <noreply@postgresql.org> writes:
> > Operating system:   MacOS
>
> > running bootstrap script ... 2019-10-19 23:25:15.095 JST [51410] FATAL:
> > could not create semaphores: No space left on device
> > 2019-10-19 23:25:15.095 JST [51410] DETAIL:  Failed system call was
> > semget(5432226, 17, 03600).
>
> That's a bit odd.  macOS is known to have low default limits for
> SysV shared memory, but not for semaphores.  Which macOS version
> are you running, exactly?  What do you get from
>         sysctl -a | grep sysv.sem
> ?  I get
>
> kern.sysv.semmni: 87381
> kern.sysv.semmns: 87381
> kern.sysv.semmnu: 87381
> kern.sysv.semmsl: 87381
> kern.sysv.semume: 10
>
> (and not only in Catalina, but very ancient mac versions)
>
> Is it possible that something else is chewing up semaphores?
> Looking at "sudo ipcs -s" output would reveal that.

I have seen a Mac get into that state a couple of times after much
uptime and much hacking and testing, and had to clean them up manually
with ipcrm.   Perhaps the occasional kill -9 (don't try this at home)
or postmaster crash, with some bad luck I guess IpcSemaphoreCreate()
could be fooled by a PID that has been recycled, and decide not to
recycle the sema?  I don't think it's anything to do with macOS
really, just the fact that we don't use SysV flavoured semaphores
elsewhere and even then most people don't do weird things to their
PostgreSQL clusters like pgsql-hackers denizens...