Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Mon, Jul 15, 2013 at 03:14:43PM +0100, Simon McVittie wrote:
> On 15/07/13 14:38, Helmut Grohne wrote:
> > Indeed we are out of luck with Type=forking. In the presence of a decent
> > init system daemonizing is the job of the init system. It is uselessly
> > duplicated code. Let's rip that code out of daemons and turn them into
> > "simple" ones.
>
> It does matter where there are dependencies. systemd considers "simple"
> services to be ready (for use by the services that depend on them) as
> soon as they have been exec'd, whereas "forking" services aren't
> considered to be ready until they have forked (and the parent process
> has exited). sysvinit scripts block as long as one of their processes
> blocks, so they automatically get that behaviour.
My comment to convert to "simple" was a bit shortsighted here. Thanks
for your clarification. When taking into account readiness the
conversion would probably arrive at "dbus" or "notify" services instead.
This is slightly more work to do, but still we can rid the useless
duplication of daemonizing code and contain it into a few places. Every
other instance of this code has bugs such as leaking file descriptors or
environment variables. We can get rid of those bugs altogether. All we
need to do here is to shift the work towards the init system as has
rightfully been done by the systemd and upstart people.
The actual argument I tried to make here was a different one. I
acknowledged that Type=forking would pose a hard to solve problem to the
proposed wrapper. The number of uses of this type is a minority though.
The reasonable thing for a wrapper to do, is not to cover this case and
stick with a few init scripts.
If the wrapper can avoid 50% of the init scripts, we have already gained
a lot in terms of maintenance cost.
Helmut
Reply to: