On Fri, 24 Apr 2020 at 12:41:01 +0200, Simon Richter wrote:
> On Thu, Apr 23, 2020 at 07:16:54PM +0100, Simon McVittie wrote:
[Simon Richter wrote:]
> > > Can maintainer scripts expect systemd services to be available (mainly
> > > thinking about tmpfilesd here, but there might be others that becom
Hi,
On Thu, Apr 23, 2020 at 07:16:54PM +0100, Simon McVittie wrote:
> policy-rc.d and invoke-rc.d are not documented in Policy to be a way to
> control what happens after you reboot, and neither sysv-rc nor systemd
> runs invoke-rc.d or consults policy-rc.d during normal system boot.
Ah, that ex
On Thu, 23 Apr 2020 at 16:59:43 +0200, Simon Richter wrote:
> The policy-rc.d mechanism is used by invoke-rc.d, which is defined as the
> appropriate way to start an init script in Policy, so sysadmins have a
> reasonable expectation that all init scripts use that mechanism.
It's documented in Pol
Am 23.04.2020 um 16:59 schrieb Simon Richter:
> As far as I can see, there is no similar mechanism in systemd that allows
> blanket refusal or logging of unknown services, only masking of known
> services by name. The method of using a custom target comes closest, is
> there a namespace of target
Thanks everybody for your help :)
On 4/22/20 4:09 PM, Simon McVittie wrote:
> [ ... ]
> In a systemd-based system, I would achieve the equivalent of #950851
> by telling systemd to start a restricted target that only contains the
> services I specifically want, instead of the default 'graphical.ta
Hi,
On Wed, Apr 22, 2020 at 03:09:13PM +0100, Simon McVittie wrote:
> In a systemd-based system, I would achieve the equivalent of #950851
> by telling systemd to start a restricted target that only contains the
> services I specifically want, instead of the default 'graphical.target'
> (targets
On Thu, 23 Apr 2020, Thomas Goirand wrote:
doesn't exist but will proceed)
- apt install foo (shipping a foo.service)
→ foo.service will not be started
Good to know, thanks!
Is https://www.freedesktop.org/software/systemd/man/systemd.preset.html
perhaps something that could help here?
-Ti
On 4/23/20 1:42 AM, Michael Biebl wrote:
> Am 23.04.20 um 00:43 schrieb Thomas Goirand:
>> On 4/22/20 4:11 PM, Sam Hartman wrote:
>
>>> And a native interface for a sysadmin overriding that (masking).
>>
>> Unless I'm mistaking, that's not useful if you want to disable starting
>> the daemon befor
Reply-To debian-devel@lists.debian.org:
In-Reply-To:
* Michael Biebl [200422 19:43]:
> Am 23.04.20 um 00:43 schrieb Thomas Goirand:
> > On 4/22/20 4:11 PM, Sam Hartman wrote:
>
> >> And a native interface for a sysadmin overriding that (masking).
> >
> > Unless I'm mistaking, that's not useful
Am 23.04.20 um 00:43 schrieb Thomas Goirand:
> On 4/22/20 4:11 PM, Sam Hartman wrote:
>> And a native interface for a sysadmin overriding that (masking).
>
> Unless I'm mistaking, that's not useful if you want to disable starting
> the daemon before installing it (ie: before the .service exists i
On 4/22/20 4:11 PM, Sam Hartman wrote:
>> "Andreas" == Andreas Henriksson writes:
>
> Andreas> Hello, FWIW I do not share Andrej Shaduras view on this. My
> Andreas> interpretation is basically the opposite. The invoke-rc.d,
> Andreas> policy-rc.d and update-rc.d policy mandated a
> "Andreas" == Andreas Henriksson writes:
Andreas> Hello, FWIW I do not share Andrej Shaduras view on this. My
Andreas> interpretation is basically the opposite. The invoke-rc.d,
Andreas> policy-rc.d and update-rc.d policy mandated abstraction is
Andreas> solely for the use of
On Wed, 22 Apr 2020 at 14:20:13 +0200, Lorenzo wrote:
> In bug #950851 the reporter says that runit is not policy compliant
> because during boot it does not check the policy-rc.d hack before
> starting sysv services.
>
> However I read policy 9.3.3 as referring to maintainer scripts (
> install,
Hello,
FWIW I do not share Andrej Shaduras view on this. My interpretation is
basically the opposite. The invoke-rc.d, policy-rc.d and
update-rc.d policy mandated abstraction is solely for the use
of maintainer scripts in debian packages (and should not be used
by init systems or elsewhere).
Note
Hi,
On Wed, 22 Apr 2020 at 14:20, Lorenzo wrote:
> Is an init required to implement a mechanism like policy-rc.d or it's
> optional?
Yes.
> It has to be policy-rc.d or it can be a different (native) one?
It has to be policy-rc.d.
--
Cheers,
Andrej
[ please keep me in CC ]
Hello,
In bug #950851 the reporter says that runit is not policy compliant
because during boot it does not check the policy-rc.d hack before
starting sysv services.
However I read policy 9.3.3 as referring to maintainer scripts (
install, upgrade, remove) but I can't fin
16 matches
Mail list logo
