On Tue, Mar 9, 2021 at 12:20 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > On 2021-Mar-03, Thomas Munro wrote: > > On Mon, Mar 1, 2021 at 2:29 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > > Time to watch the buildfarm to find out if my speculation about > > > illumos is correct... > > > > I just heard that damselfly's host has been decommissioned with no > > immediate plan for a replacement. That was the last of the > > Solaris-family animals testing master. It may be some time before I > > find out if my assumptions broke something on that OS... > > Hi, I don't know if you realized but we have two new Illumos members > now (haddock and hake), and they're both failing initdb on signalfd() > problems.
Ah, cool. I'd been discussing this with their owner, who saw my message and wanted to provide replacements. Nice to see these start up even though I don't love the colour of their first results. In off-list emails, we got as far as determining that signalfd() fails on illumos when running inside a zone (= container), because /dev/signalfd is somehow not present. Apparently it works when running on the main host. Tracing revealed that it's trying to open that device and getting ENOENT here: running bootstrap script ... FATAL: XX000: signalfd() failed LOCATION: InitializeLatchSupport, latch.c:279 I'll wait a short time while he tries to see if that can be fixed (I have no clue if it's a configuration problem in some kind of zone creation scripts, or a bug, or what). If not, my fallback plan will be to change it to default to WAIT_USE_POLL on that OS until it can be fixed.
