Tollef Fog Heen wrote:
> > Russ Allbery wrote:
> > > Bob Proulx writes:
> > > > Maybe I am missing a better alternative?
> > >
> > > update-rc.d disable
> >
> > No. That is too late. By the time you are disabling something it has
> > already been installed and started in postinst scripts. Usi
]] Bob Proulx
> Russ Allbery wrote:
> > Bob Proulx writes:
> > > Maybe I am missing a better alternative?
> >
> > update-rc.d disable
>
> No. That is too late. By the time you are disabling something it has
> already been installed and started in postinst scripts. Using
> policy-rc.d is the
Bastien ROUCARIES writes:
> Le 19 nov. 2014 21:33, "Russ Allbery" a écrit :
>> Yes, absolutely. Likewise for cron jobs, etc. That's something that I
>> don't think we're doing a great job of right now, and really should
>> improve.
> Could lintian help here ?
Yes, although it's tricky.
If a
Le 19 nov. 2014 21:33, "Russ Allbery" a écrit :
>
> Jonas Smedegaard writes:
>
> > Which implies, I believe, that any other way of starting daemons should
> > also respect policy-rc.d if it can lead to automated triggering.
>
> > Example: if a logrotate snippet uses "update-rc.d force-restart ...
Quoting Simon McVittie (2014-11-19 21:49:49)
> On 19/11/14 19:41, Jonas Smedegaard wrote:
>> Example: if a logrotate snippet uses "update-rc.d force-restart ..."
>> then suppressing that deamon with policy-rc.d will be circumvented
>> when cron triggers log rotation.
>
> If it uses "update-rc.d f
Simon McVittie writes:
> If you meant service, I think the answer is "that's a bug". service
> intentionally doesn't respect "enabledness" either, under at least
> sysvinit and systemd, so it's a bug even in the absence of policy-rc.d.
Right, service is a tool for the local administrator. servi
On 19/11/14 19:41, Jonas Smedegaard wrote:
> Example: if a logrotate snippet uses "update-rc.d force-restart ..."
> then suppressing that deamon with policy-rc.d will be circumvented when
> cron triggers log rotation.
If it uses "update-rc.d force-restart" then it will fail, because that
isn't a
Jonas Smedegaard writes:
> Which implies, I believe, that any other way of starting daemons should
> also respect policy-rc.d if it can lead to automated triggering.
> Example: if a logrotate snippet uses "update-rc.d force-restart ..."
> then suppressing that deamon with policy-rc.d will be c
Quoting Russ Allbery (2014-11-19 19:28:09)
> Bob Proulx writes:
>
> > No. That is too late. By the time you are disabling something it has
> > already been installed and started in postinst scripts. Using
> > policy-rc.d is the only way to prevent unknown anythings from being
> > enabled befor
Bob Proulx writes:
> No. That is too late. By the time you are disabling something it has
> already been installed and started in postinst scripts. Using
> policy-rc.d is the only way to prevent unknown anythings from being
> enabled before installing.
Ah, yes, that's true.
> P.S. Related to
Russ Allbery wrote:
> Bob Proulx writes:
> > Maybe I am missing a better alternative?
>
> update-rc.d disable
No. That is too late. By the time you are disabling something it has
already been installed and started in postinst scripts. Using
policy-rc.d is the only way to prevent unknown anyth
On Tue, Nov 18, 2014, at 10:25, Simon McVittie wrote:
> We already have a way to disable services, which knows about sysvinit,
> systemd and Upstart despite its unfortunate name (update-rc.d).
Perhaps we could provide an alternative name to this: f.e.
init-maintscript-helper would reflect the inte
On 18/11/14 02:02, Bob Proulx wrote:
> Here it is said update-rc.d does not respect policy-rc.d but I think
> maybe that should have been invoke-rc.d since update-rc.d just sets
> things up to start while it is invoke-rc.d that actually does it.
invoke-rc.d is the only thing that *does* respect po
Bob Proulx writes:
> Henrique de Moraes Holschuh wrote:
>> Anthony Towns wrote:
>>> Followup question: does anyone actually use the detailed features of
>>> policy-rc.d or is always used in practice to turn all init scripts off?
>> I think I heard of someone using them *once*. It is very rare,
Henrique de Moraes Holschuh wrote:
> Anthony Towns wrote:
> > Russ Allbery wrote:
> > > Anthony Towns writes:
> > > > BTW, it occured to me that it seems like a wart that update-rc.d doesn't
> > > > respect policy-rc.d -- as it stands, policy-rc.d can prevent a service
> > > > from (re)starting dur
On Mon, 17 Nov 2014, Russ Allbery wrote:
> Henrique de Moraes Holschuh writes:
> > I think I heard of someone using them *once*. It is very rare, AFAIK.
>
> > However, if there is one thing I learned the hard way, is that people
> > who use the advanced features don't make themselves or that fac
Henrique de Moraes Holschuh writes:
> I think I heard of someone using them *once*. It is very rare, AFAIK.
> However, if there is one thing I learned the hard way, is that people
> who use the advanced features don't make themselves or that fact known
> unless you ask. They often don't show u
On Mon, 17 Nov 2014, Anthony Towns wrote:
> On Mon, Nov 17, 2014 at 09:22:39AM -0800, Russ Allbery wrote:
> > Anthony Towns writes:
> > > BTW, it occured to me that it seems like a wart that update-rc.d doesn't
> > > respect policy-rc.d -- as it stands, policy-rc.d can prevent a service
> > > from
On Mon, Nov 17, 2014 at 09:22:39AM -0800, Russ Allbery wrote:
> Anthony Towns writes:
> > BTW, it occured to me that it seems like a wart that update-rc.d doesn't
> > respect policy-rc.d -- as it stands, policy-rc.d can prevent a service
> > from (re)starting during install/upgrade, but it'll stil
On Mon, 17 Nov 2014, Anthony Towns wrote:
> On Mon, Nov 17, 2014 at 02:38:04PM -0200, Henrique de Moraes Holschuh wrote:
> > On Mon, 17 Nov 2014, Anthony Towns wrote:
> > > If deb-systemd-* were to get merged in, it might be worth doing a name
> > > change at the same time, I guess. Changing either
Am 2014-11-17 18:07, schrieb Anthony Towns:
BTW, it occured to me that it seems like a wart that update-rc.d
doesn't
respect policy-rc.d -- as it stands, policy-rc.d can prevent a
service
from (re)starting during install/upgrade, but it'll still start on
the
next boot. Is that just something t
Anthony Towns writes:
> BTW, it occured to me that it seems like a wart that update-rc.d doesn't
> respect policy-rc.d -- as it stands, policy-rc.d can prevent a service
> from (re)starting during install/upgrade, but it'll still start on the
> next boot. Is that just something that never got tho
On 11/17/2014 10:36 PM, Anthony Towns wrote:
> I wonder if it would make sense to just merge it all into the "service"
> command; ie:
>
># service --use-policy ssh start
># service --use-policy ssh restart
># service ssh enable
># service acpid.socket mask-for-upgrade
>
> in place
On Mon, Nov 17, 2014 at 02:38:04PM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 17 Nov 2014, Anthony Towns wrote:
> > If deb-systemd-* were to get merged in, it might be worth doing a name
> > change at the same time, I guess. Changing either before jessie doesn't
> > seem remotely plausible
On Mon, 17 Nov 2014, Anthony Towns wrote:
> If deb-systemd-* were to get merged in, it might be worth doing a name
> change at the same time, I guess. Changing either before jessie doesn't
> seem remotely plausible.
>
> I wonder if it would make sense to just merge it all into the "service"
> comm
On Mon, Nov 17, 2014 at 10:10:58AM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 17 Nov 2014, Anthony Towns wrote:
> > Having a single tool that does the basic stuff admins and maintainers need
> > independent of init system seems like the right approach to me. "*-rc.d"
> > is a terrible name
Hi,
Henrique de Moraes Holschuh:
> On Mon, 17 Nov 2014, Anthony Towns wrote:
> > Having a single tool that does the basic stuff admins and maintainers need
> > independent of init system seems like the right approach to me. "*-rc.d"
> > is a terrible name for such a tool, though :(
>
> Err, yes.
On Mon, 17 Nov 2014, Anthony Towns wrote:
> Having a single tool that does the basic stuff admins and maintainers need
> independent of init system seems like the right approach to me. "*-rc.d"
> is a terrible name for such a tool, though :(
Err, yes. There were complains about the -rc.d prefix w
On Sun, Nov 16, 2014 at 01:43:37PM -0800, Steve Langasek wrote:
> Can someone of the systemd maintainers please explain why this is being done
> as a separate helper instead of integrating with the tools that are already
> defined in policy and already part of the base system (e.g., invoke-rc.d)?
Steve Langasek writes:
> I am very concerned about the promulgation of init-system-helpers in
> general. This helper package has started pulling bloated dependencies
> into our base system (bug #757891),
I think this is resolved. All of the Perl modules it required except for
File::Temp and it
On Sat, Nov 15, 2014 at 06:06:17PM +0100, Bastien ROUCARIES wrote:
> In order to solve #769551 I need to Pre-Depends: init-system-helpers
> Indeed preinst script need it:
> /var/lib/dpkg/tmp.ci/preinst: 27: /var/lib/dpkg/tmp.ci/preinst:
> deb-systemd-helper: not found
> Thus I am
On 11/16/2014 05:14 AM, Bastien ROUCARIES wrote:
>
> Le 15 nov. 2014 19:18, "Bastian Blank" <mailto:wa...@debian.org>> a écrit :
>>
>> On Sat, Nov 15, 2014 at 06:06:17PM +0100, Bastien ROUCARIES wrote:
>> > In order to solve #769551 I need to Pre-De
Le 15 nov. 2014 19:18, "Bastian Blank" a écrit :
>
> On Sat, Nov 15, 2014 at 06:06:17PM +0100, Bastien ROUCARIES wrote:
> > In order to solve #769551 I need to Pre-Depends: init-system-helpers
> > Indeed preinst script need it:
> > /var/lib/dpkg/tmp.ci/preinst
On Sat, Nov 15, 2014 at 06:06:17PM +0100, Bastien ROUCARIES wrote:
> In order to solve #769551 I need to Pre-Depends: init-system-helpers
> Indeed preinst script need it:
> /var/lib/dpkg/tmp.ci/preinst: 27: /var/lib/dpkg/tmp.ci/preinst:
> deb-systemd-helper: not found
Why do you need
Hi,
In order to solve #769551 I need to Pre-Depends: init-system-helpers
Indeed preinst script need it:
/var/lib/dpkg/tmp.ci/preinst: 27: /var/lib/dpkg/tmp.ci/preinst:
deb-systemd-helper: not found
Thus I am asking to add a pre-depends to init-system-helpers
--
To UNSUBSCRIBE, email to
35 matches
Mail list logo
