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

On Thu, 6 Nov 2014 22:21:25 -0500 Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= wrote: > On Thu, Nov 06, 2014 at 01:25:32PM -0800, Josh Triplett wrote: > > On Wed, 5 Nov 2014 20:20:27 -0500 Zbigniew > > =?utf-8?Q?J=C4=99drzejewski-Szmek?= wrote: > > > On Wed,

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

On Wed, 5 Nov 2014 20:20:27 -0500 Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= zjedr...@gmu.edu wrote: On Wed, Nov 05, 2014 at 07:31:32PM +0100, Michael Biebl wrote: The default for sysv init scripts is RemainAfterExit=true [0], so even if there are no running processes, the service is

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

On Thu, Nov 06, 2014 at 01:25:32PM -0800, Josh Triplett wrote: On Wed, 5 Nov 2014 20:20:27 -0500 Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= zjedr...@gmu.edu wrote: On Wed, Nov 05, 2014 at 07:31:32PM +0100, Michael Biebl wrote: The default for sysv init scripts is RemainAfterExit=true

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

Package: systemd Version: 215-5+b1 Severity: important Hi, systemd is breaking unrelated software and preventing it from starting normally: (Results below are the same if you call /etc/init.d/fp-facilitator directly, instead of service fp-facilitator) $ sudo aptitude install

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

Am 05.11.2014 um 19:05 schrieb Ximin Luo: Package: systemd Version: 215-5+b1 Severity: important Hi, systemd is breaking unrelated software and preventing it from starting normally: Well, the title of this bug report is misleading and wrong. I'll try to explain what you're encountering.

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

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

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

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

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

retitle 768178 LSB/SysV service incorrectly marked as active under certain conditions, breaking the start sysvinit subcommand thanks On 05/11/14 19:46, Michael Biebl wrote: sysvinit is stateless, systemd is not. systemd keeps track of services, no matter if they are described by native

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

On Wed, Nov 05, 2014 at 08:12:39PM +, Ximin Luo wrote: All I care is that service x start works. It does not. This is correctly called systemd breaks existing software - it is breaking the sysvinit behaviour. Let's look what LSB says:

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

On 05/11/14 20:54, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Nov 05, 2014 at 08:12:39PM +, Ximin Luo wrote: All I care is that service x start works. It does not. This is correctly called systemd breaks existing software - it is breaking the sysvinit behaviour. Let's look what LSB

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

On 05/11/14 21:52, Ximin Luo wrote: On 05/11/14 20:54, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Nov 05, 2014 at 08:12:39PM +, Ximin Luo wrote: All I care is that service x start works. It does not. This is correctly called systemd breaks existing software - it is breaking the sysvinit

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

On Wed, Nov 05, 2014 at 07:31:32PM +0100, Michael Biebl wrote: 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