aintainer scripts
> > (driven by dh_installtmpfiles), without taking policy-rc.d into account.
>
> Yes, I stumbled across this mostly because samba now fails to configure on
> sysvinit systems because /var/run/samba is missing -- so there is an
> expectation the maintainer script has tha
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.
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
ce of target names that can be used by sysadmins that will
> never conflict with upstream target names?
Just in case this is not obvious to everyone:
deb-systemd-invoke (which is what's used in maintainer scripts of
packages using dh_installsystemd) does respect policy-rc.d (although
pol
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
ugh one of
the automation frameworks?
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. We have
two custom implementations in the archive (p
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,
> Andrea
>>>>> "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
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 scri
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
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&#
ages from upgrades. While
> > this is useful in its own right, I think we should eventually provide an
> > easy-to-configure policy-rc.d mechanism (possibly integrated with
> > debconf?) to provide what most people eventually want: a "please don't
> > restart my a
in its own right, I think we should eventually provide an
> easy-to-configure policy-rc.d mechanism (possibly integrated with
> debconf?) to provide what most people eventually want: a "please don't
> restart my apache or mysql automatically" kind of behaviour.
need
.
Currently unattended-upgrades provides a package blacklist that can be
manually configured to exclude certain packages from upgrades. While
this is useful in its own right, I think we should eventually provide an
easy-to-configure policy-rc.d mechanism (possibly integrated with
debconf?) to provi
On Tue, 25 Jan 2005 11:03:16 -0200, Henrique de Moraes Holschuh
<[EMAIL PROTECTED]> wrote:
>On Tue, 25 Jan 2005, Marc Haber wrote:
>> So policy-rc.d needs to be in /usr/local, or we have a FHS violation.
>
>Please request that we enhance invoke-rc.d to look on /usr/local fi
On Tue, Jan 25, 2005 at 09:32:02AM +0100, Marc Haber wrote:
> So policy-rc.d needs to be in /usr/local, or we have a FHS violation.
> Additionally, the requirement of going through the alternatives system
> for policy-rc.d selection is somewhat mis-placed, because it suggests
> to me
Scripsit Marc Haber <[EMAIL PROTECTED]>
> On Tue, 25 Jan 2005 18:44:42 +1100, Matthew Palmer
>>Steve answered your first question. The second question makes no sense,
>>since policy-rc.d is supposed to be written by the administrator to fit
>>their local policy.
>
On Tue, 25 Jan 2005, Marc Haber wrote:
> So policy-rc.d needs to be in /usr/local, or we have a FHS violation.
Please request that we enhance invoke-rc.d to look on /usr/local first,
then (through a wishlist bug). Looks like a good idea at first glance.
> Additionally, the requirement of
your first question. The second question makes no sense,
>since policy-rc.d is supposed to be written by the administrator to fit
>their local policy.
So policy-rc.d needs to be in /usr/local, or we have a FHS violation.
Additionally, the requirement of going through the alternatives system
for
begin Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Sat, 22 Nov 2003, Joerg Sommer wrote:
>> I hope someone knows what policy-rc.d is and can comment my idea, because
>> the maintainer of file-rc will stay conform to sysv-rc, which uses
>> policy-rc.d.
&
On Thu, 03 Jul 2003, Marc Singer wrote:
> > Take a look at invoke-rc.d and its policy program.
>
> OK. I can tell that this feature is available, though obscured by the
> lack of a man page for policy-rc.d or even a reference to a package
> that implements it. I *did* find
s or
> > changing the executability of the init.d script.
>
> Take a look at invoke-rc.d and its policy program.
OK. I can tell that this feature is available, though obscured by the
lack of a man page for policy-rc.d or even a reference to a package
that implements it. I *did* find a
27 matches
Mail list logo
