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

[Michael Biebl]

retitle 768178 LSB/SysV service incorrectly marked as active under certain conditions
thanks

Am 05.11.2014 um 19:50 schrieb 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?

I'm not quite sure what you mean by sysvinit wrapper.
SysV init scripts are just another source for service definitions.

In a plain sysvinit setup (that
> does not have systemd interfering with things) "start" is run 
> unconditionally if I say "service x start".

That's not quite true. The service is not started unconditionally, but rather start-stop-daemon will check, if the service is running and do nothing if the service is already running.
Under systemd, that check is moved into systemd directly.
We rely on the SysV init scripts to report proper return states, so we can properly mark the state of services.
By using ENABLE flags and returning 0 you circumvent that the service is correctly marked.

 What is the problem with
> doing things this way?

sysvinit is stateless, systemd is not. systemd keeps track of services, no matter if they are described by native .service files or SysV init scripts.

If you run "service fp-facilitator start", and this returns 0, system will mark the service as correctly started.

>> 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.

It's not breaking existing software, but the behaviour is different.

>> 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.

I can't see how this can be addressed in systemd as long as SysV init scripts do not provide the necessary meta data.

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

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