Bug#568385: gracie: daemonizes too late, ends up with socket closed

[Ben Finney]

I am testing a fix for this in the upstream code. The daemon context
now receives the HTTP server socket file descriptor, and is told not
to close that file descriptor. (This uses the ‘files_exclude’ option of
the DaemonContext instance.)

The command I'm using to test this in the upstream codebase is:

    PYTHONPATH=. strace -f -s 1024 bin/gracied --pidfile /tmp/gracied.pid 
--data-dir /tmp/gracie --host 127.0.0.1 --port 8123 2> /tmp/gracied.$(date 
+'%Y%m%d').strace

The result of the change is that the tail end of the trace now looks
like:

=====
[…]
close(6)                                = -1 EBADF (Bad file descriptor)
close(5)                                = -1 EBADF (Bad file descriptor)
close(4)                                = -1 EBADF (Bad file descriptor)
close(1)                                = 0
close(0)                                = 0
open("/dev/null", O_RDWR|O_LARGEFILE)   = 0
dup2(0, 0)                              = 0
open("/dev/null", O_RDWR|O_LARGEFILE)   = 1
dup2(1, 1)                              = 1
open("/dev/null", O_RDWR|O_LARGEFILE)   = 4
dup2(4, 2)                              = 2
open("/tmp/fuschia.MainThread-17293", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 
0666) = 5
fstat64(0x5, 0xffa07b88)                = 0
close(5)                                = 0
link("/tmp/fuschia.MainThread-17293", "/tmp/gracied.pid.lock") = 0
open("/tmp/gracied.pid", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 5
fcntl64(5, F_GETFL)                     = 0x10001 (flags O_WRONLY|O_LARGEFILE)
fstat64(0x5, 0xffa07b88)                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf7ce5000
_llseek(5, 0, [0], SEEK_CUR)            = 0
fstat64(0x5, 0xffa07c68)                = 0
write(5, "17296\n", 6)                  = 6
close(5)                                = 0
munmap(0xf7ce5000, 4096)                = 0
accept(3, 0xffa07c84, [16])             = ? ERESTARTSYS (To be restarted)
=====

The server is now accepting connections on the socket.

I don't understand the “ERESTARTSYS (To be restarted)” result from the
‘accept’ call. The ‘accept(2)’ manpage says:

=====
ERRORS
[…]

        In  addition,  network  errors  for the new socket and as
        defined for the protocol may be returned.  Various Linux
        kernels can return other errors such as ENOSR,
        ESOCKTNOSUPPORT, EPROTONOSUPPORT, ETIMEDOUT. The value
        ERESTARTSYS may be seen during a trace.
=====

There's no explanation of what the ‘ERESTARTSYS’ error condition
means, though. Do you have any idea what is causing this?

-- 
 \        “Somebody told me how frightening it was how much topsoil we |
  `\   are losing each year, but I told that story around the campfire |
_o__)                             and nobody got scared.” —Jack Handey |
Ben Finney <b...@benfinney.id.au>

signature.asc
Description: Digital signature