Bug#768178: systemd: sysvinit wrapper breaks newly-installed services

[Ximin Luo]

On 05/11/14 18:31, Michael Biebl wrote:
> 
> Since flashproxy-facilitator uses "invoke-rc.d flashproxy-facilitator
> start" in postinst, the state of the service is "active (exited)" at
> this point.
> 
> The default for sysv init scripts is RemainAfterExit=true [0], so even
> if there are no running processes, the service is marked as active.
> This is because systemd doesn't know, if the sysv init script is
> supposed to start a long running process or a just some one shot commands.
> 
> [..]
> 
> If the service is already considered active, a start will be no-op.
> 

I think this is the bug on systemd's part. I get that "start is a no-op" might make sense for actual systemd services, but how does it make sense for the sysvinit wrapper? In a plain sysvinit setup (that does not have systemd interfering with things) "start" is run unconditionally if I say "service x start". What is the problem with doing things this way?

> 
> systemd doesn't clobber any variables. The problem here is, that the
> service is considered active, even though it isn't really, since it has
> been neutered via the ENABLE flag. Therefore, such ENABLE or RUN_DAEMON
> flags in /etc/default/ should be avoided.
> 

Er, I wrote a "sysvinit" script, not a systemd script. As far as I know, there is no sysvinit standard that forbids ENABLE or RUN_DAEMON, even if it is "discouraged".

If systemd wants to kludge wrappers for sysvinit, it's the *responsibility of systemd* to not break existing software.

> A few recommendations
> - Avoid such ENABLE flags in /etc/default/<service>
> - Ship a native .service file to explicitly tell systemd about the type
> of service [1] so it can track it more reliably.
> - Iif you want to stick with sysv init scripts but tell systemd that the
> sysv init script runs a long running process, add a
> # pidfile: /var/run/foo.pid
> pseudo header.
> 

I can do these things, and thanks for the explanation - but this issue is still systemd's fault, that should be fixed ultimately on the systemd side.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20141105/47af010f/attachment-0002.sig>