Tollef Fog Heen wrote:
Russ Allbery wrote:
Bob Proulx writes:
Maybe I am missing a better alternative?
update-rc.d service disable
No. That is too late. By the time you are disabling something it has
already been installed and started in postinst scripts. Using
Le 19 nov. 2014 21:33, Russ Allbery r...@debian.org a écrit :
Jonas Smedegaard d...@jones.dk 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
Bastien ROUCARIES roucaries.bast...@gmail.com writes:
Le 19 nov. 2014 21:33, Russ Allbery r...@debian.org 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 ?
]] Bob Proulx
Russ Allbery wrote:
Bob Proulx writes:
Maybe I am missing a better alternative?
update-rc.d service 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
Russ Allbery wrote:
Bob Proulx writes:
Maybe I am missing a better alternative?
update-rc.d service 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
Bob Proulx b...@proulx.com 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.
Quoting Russ Allbery (2014-11-19 19:28:09)
Bob Proulx b...@proulx.com 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
Jonas Smedegaard d...@jones.dk 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
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
Simon McVittie s...@debian.org 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
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
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
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
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 way
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. There
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 for
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
command;
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 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 of:
Anthony Towns a...@erisian.com.au 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
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
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 before
On Mon, Nov 17, 2014 at 09:22:39AM -0800, Russ Allbery wrote:
Anthony Towns a...@erisian.com.au 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,
On Mon, 17 Nov 2014, Anthony Towns wrote:
On Mon, Nov 17, 2014 at 09:22:39AM -0800, Russ Allbery wrote:
Anthony Towns a...@erisian.com.au 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
Henrique de Moraes Holschuh h...@debian.org 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
On Mon, 17 Nov 2014, Russ Allbery wrote:
Henrique de Moraes Holschuh h...@debian.org 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
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 during
Bob Proulx b...@proulx.com 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
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 asking to add a pre
Steve Langasek vor...@debian.org 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
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)?
I
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
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 deb-systemd
Le 15 nov. 2014 19:18, Bastian Blank 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-Depends: init-system-helpers
Indeed preinst script need it:
/var/lib/dpkg/tmp.ci/preinst: 27: /var/lib/dpkg/tmp.ci
On 11/16/2014 05:14 AM, Bastien ROUCARIES wrote:
Le 15 nov. 2014 19:18, Bastian Blank wa...@debian.org
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-Depends: init-system-helpers
Indeed preinst
35 matches
Mail list logo
