[Toybox] [PATCH] Factor out dhcpd's and syslogd's main loops into a library function

[Felix Janda]

Rob Landley wrote:
> Taking the remaining holiday time to close old reply windows and such.  
> I've ahd this one open a while... :)
> 
> On 09/06/2013 05:35:27 PM, Felix Janda wrote:
[...]
> > > Are we normally blocking a lot of signals in other commands? Using  
> > the
> > > 6 argument version instead of the 5 argument version addresses an  
> > issue
> > > for which existing command?
> > 
> > If a signal occurs during the block it will still be delivered in the  
> > next
> > pselect loop. pselect implements exactly the signal unblocking I am  
> > talking
> > about above. We block all signals. But during the signal call some are
> > unblocked. When it returns they are again blocked and we can safely  
> > check
> > what has happened. See the article
> > 
> > https://lwn.net/Articles/176911/
> > 
> > for some discussion on the system call.
> 
> My problem with the approach was that the loop really shouldn't mess  
> with signal handlers at all. If we want to fiddle with something fancy  
> there's signalfd.

Ok, I see that in the case that in the case that no signal handling is
needed it shouldn't touch the sigprocmask at all.

In the case signal handling is needed the blocking tames the
asynchronic signals. signalfd would be another (linux specific) option.

> I have an aversion to "infrastructure in search of a user". When common  
> code goes into the library, I like to be able to point to at least one  
> existing user, preferably two.

For me the whole point was factoring out the similar code in dhcpd and
syslogd (now there are more possible users in pending), replacing the
self-pipes by something of similar functionality but better suited to
be put into a function.

[...]
> > select() adjusts its timespecs on linux. But that's only one possible
> > behavior specified by POSIX.
> 
> Some not-linuxes don't work like linux, posix is vague enough to allow  
> Windows NT to be certified...
> 
> I'm pretty happy sticking with a documented Linux semantic if it's a  
> documented Linux semantic.

Ok. (But it'd be good to note somewhere that a Linux semantic is used.)

> > Since we are already doing signals SIGALRM
> > seemed more elegant then constantly adjusting the timeout to me.
> 
> Having a library I/O function modify global signal handler state is  
> elegant?

"more elegant". (Oh, s/then/than/) daemon_main_loop() says how much I
thought of it as a library I/O function at the start. It is meant to
take total control of all signals. I can't think of any application
(in toybox) of both signals and a poll/select loop but a
wait-for-fd-or-signal-loop.

[...] (Discussion on fork and exec.)

> > > > Since xexec()
> > > > doesn't change the pid the pidfile needs to be unlinked() before
> > > > terminating so that xpidfile() doesn't complain.
> > >
> > > Um... I agree this is a symptom of a problem. I'm not sure that's  
> > the
> > > right fix. The restart is maintaining state and then getting  
> > confused
> > > by the state it's maintaining...
> > >
> > > (I can just see some horrible systemd thing hitting a race window  
> > where
> > > the PID file wasn't there and trying to restart the process...)
> > 
> > Does systemd still need PID files?
> 
> I have no idea. It's a horrible thing and I'm trying to avoid it. My  
> point was not assuming behavior on the part of other programs, and  
> leaving a window where something doing inotify() wakes up because an  
> indicator file went away when the process it represents didn't and  
> isn't going to... I try to avoid that sort of halfway state where there  
> can be conflicting assumptions.

So build in some extra logic so that the PID file is only deleted if the
daemon actually exits?

[...]
> > So how about making the two helper functions for daemon_main_loop()
> > return a value and possibly returning from daemon_main_loop() based on
> > that value? Then in syslogd_main() add a infinite loop around (or  
> > almost)
> > everything.
> 
> I need to go clean up dhcpd and systemd before figuring out what the  
> infrastructure should look like. If we're going to do anything fancy  
> with signals I lean towards teaching this loop about signalfd, but  
> probably since Linux can adjust the timeout we should just let Linux  
> adjust the timeout.

Apart from the portability I'd also be very much happy with signalfd.
Again pselect is a replacement for the __self-pipes__. The timeout
is just a side show.

> Lemme finish my current set of cleanups, then get back to this. :)

Take your time.

> I'm finally sort of resurfacing from A) catching up on domestic life  
> after 6 months out of state, B) starting a new job after the  
> kickstarter idea got zero replies.

I have no valuable input on the proposed text for the campaign
(like it as it is) but would really like something like it to happen
(and succeed). The current state is kind of sad. (There is no way
to blame you for it.)

Felix