]] Micah Anderson
Hi,
| Also insserv is Priority: optional, so we can't count on that being on
| every system.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551745 is already
filed. I have no idea why it hasn't been fixed yet, it looks like a
trivial change.
--
Tollef Fog Heen
UNIX is
Am 22.03.2011 07:10, schrieb Tollef Fog Heen:
]] Micah Anderson
Hi,
| Also insserv is Priority: optional, so we can't count on that being on
| every system.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551745 is already
filed. I have no idea why it hasn't been fixed yet, it looks
Tollef Fog Heen tfh...@err.no writes:
- install configuration using puppet/chef/cfengine/etc
Speaking of, the the changes that were made in Debian Squeeze to
update-rc.d to accommodate for dependency-based booting broke puppet’s
functionality to enable/disable services properly (#573551). Its
Raphael Geissert geiss...@debian.org writes:
That means:
# mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2
# insserv # this bit is not documented, it seems
Is using insserv directly really the right interface? Correct me if I am
wrong, but if you decided to opt-out of dependency-based
On Thu, Mar 10, 2011 at 12:59:46AM +0200, Timo Juhani Lindfors wrote:
Serafeim Zanikolas s...@debian.org writes:
sysv-rc-conf works for any symlink-based system.
If you want to make sure that only carefully chosen services are ever
running then you still need to maintain your own
Serafeim Zanikolas s...@debian.org writes:
On Thu, Mar 10, 2011 at 12:59:46AM +0200, Timo Juhani Lindfors wrote:
If you want to make sure that only carefully chosen services are ever
running then you still need to maintain your own /usr/sbin/policy-rc.d
For symlink-based init systems,
Am 20.03.2011 16:14, schrieb Timo Juhani Lindfors:
Serafeim Zanikolas s...@debian.org writes:
On Thu, Mar 10, 2011 at 12:59:46AM +0200, Timo Juhani Lindfors wrote:
If you want to make sure that only carefully chosen services are ever
running then you still need to maintain your own
Michael Biebl bi...@debian.org writes:
Not true. If a service has been disabled (by renaming S* to K*) invoke-rc.d
honours that and does not start the service.
Interesting. With
$ echo /etc/rc*/*avahi-daemon
/etc/rc0.d/K02avahi-daemon /etc/rc1.d/K02avahi-daemon
/etc/rc2.d/K02avahi-daemon
On Wed, Mar 02, 2011 at 11:54:05AM -0800, Steve Langasek wrote [edited]:
On Wed, Mar 02, 2011 at 03:42:28PM +0200, Faidon Liambotis wrote:
[..]
Are you serious? How's that a sysadmin interface? Yes, everything can be
done using sh/cp/mv/vi, but this is hardly something that's either
Serafeim Zanikolas s...@debian.org writes:
sysv-rc-conf works for any symlink-based system.
If you want to make sure that only carefully chosen services are ever
running then you still need to maintain your own /usr/sbin/policy-rc.d
and keep it in sync with sysv-rc-conf.
--
To UNSUBSCRIBE,
The use case for this is:
- install daemon
- install configuration using puppet/chef/cfengine/etc
- start daemon or hook daemon into tool that keeps it running (monit,
god, etc)
Is there any reason against using a debconf script that asks if the daemon
should be started at boot time (or
]] Bastian Blywis
Hi,
| The use case for this is:
|
| - install daemon
| - install configuration using puppet/chef/cfengine/etc
| - start daemon or hook daemon into tool that keeps it running (monit,
|god, etc)
|
| Is there any reason against using a debconf script that asks if the
|
On Thu, Mar 3, 2011 at 7:25 AM, Tollef Fog Heen tfh...@err.no wrote:
- install daemon
- install configuration using puppet/chef/cfengine/etc
- start daemon or hook daemon into tool that keeps it running (monit,
god, etc)
Can't you either install the config before installing the daemon or
Drake Wilson writes (Re: enable/disable flags in /etc/default):
Quoth Bob Proulx b...@proulx.com, on 2011-03-02 17:00:19 -0700:
Having daemons started automatically at installation time is a very
nice feature of Debian IMNHO.
Is there any harder data on which behavior various proportions
On Thu, 2011-03-03 at 10:37 +0100, Tollef Fog Heen wrote:
| Is there any reason against using a debconf script that asks if the
| daemon should be started at boot time (or on which runlevels)? That
| way you can easily modify the configuration with dpkg-reconfigure and
| benefit from the
On Tue, Mar 01, 2011 at 08:30:24PM +0100, Olaf van der Spek wrote:
time the package is upgraded. i mean, it's not even that great for
maintainer scripts, as evidenced by the total inconsistency for how
developers are managing enabling/disabling of their services.
Isn't that handled by DH
hi zack,
On Wed, Mar 02, 2011 at 09:41:18AM +0100, Stefano Zacchiroli wrote:
without telling which those several tools are. According to this
thread, the recommended tool among them is mv (in the hope that the
sysadm knows by heart that they have to run insserv afterwards).
there's a few
(Cross-posting to d-d-games for discussion of the Quake III-based games)
On Tue, 01 Mar 2011 at 15:20:52 -0800, Russ Allbery wrote:
Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
variables in some of my packages
Speaking as another implementor of similar variables: I added
Hi!
As someone who is also annoyed by the default file startup hack (which
is IMHO an abuse because why have a S rc link then?), let me also throw
in my 0.02 EUR.
Stig Sandbeck Mathisen s...@debian.org writes:
The short term issue is figuring out if the current practice of
On Wed, Mar 02, 2011 at 12:37:25PM +, Simon McVittie wrote [edited]:
(Cross-posting to d-d-games for discussion of the Quake III-based games)
On Tue, 01 Mar 2011 at 15:20:52 -0800, Russ Allbery wrote:
Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
variables in some
On 03/02/11 05:24, Raphael Geissert wrote:
Interesting that everyone talks about update-rc.d but it appears that nobody
has read its documentation:
A common system administration error is to delete the links with
the thought that this will disable the service, i.e., that this will
prevent
Simon McVittie wrote:
The other good option I've seen for packages where the init script isn't
necessarily the preferred way to run the server is to split the package,
so the server binary and supporting files are in one binary package (e.g.
dnsmasq-base, git-daemon, mysql-server-core-5.1) and
On Wed, Mar 02, 2011 at 03:42:28PM +0200, Faidon Liambotis wrote:
That means:
# mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2
# insserv # this bit is not documented, it seems
Are you serious? How's that a sysadmin interface? Yes, everything can be
done using sh/cp/mv/vi, but this is
On 2011-03-02 20:54 +0100, Steve Langasek wrote:
On Wed, Mar 02, 2011 at 03:42:28PM +0200, Faidon Liambotis wrote:
Also, while we're at update-rc.d's documentation, that particular
manpage says:
Example of disabling a service:
update-rc.d -f foobar remove
Stig Sandbeck Mathisen wrote:
Currently, our packaged services start automatically, unless explicitly
disabled in /etc/default/service, or by missing configuration.
Having daemons started automatically at installation time is a very
nice feature of Debian IMNHO. And by comparison it really
(Sorry for the duplicate, Bob; forgot to send to list first time.)
Quoth Bob Proulx b...@proulx.com, on 2011-03-02 17:00:19 -0700:
Having daemons started automatically at installation time is a very
nice feature of Debian IMNHO.
Is there any harder data on which behavior various proportions or
]] Drake Wilson
| (Sorry for the duplicate, Bob; forgot to send to list first time.)
|
| Quoth Bob Proulx b...@proulx.com, on 2011-03-02 17:00:19 -0700:
| Having daemons started automatically at installation time is a very
| nice feature of Debian IMNHO.
|
| Is there any harder data on which
Hi!
Some things usually spin in my head for days and I come up with an idea
that looks sane at first sight. This might be such a moment, and I
wonder wether there might be something that I overlooked here:
* Gerfried Fuchs rho...@deb.at [2011-03-02 14:47:22 CET]:
Actually I explicitly
...
Before someone starts to nitpick it and distract from the real content:
* Gerfried Fuchs rho...@deb.at [2011-03-03 07:58:59 CET]:
#v+
# only on new install
if [ $1 = configure ] [ x$2 = x ]; then
update-rc.d foo defaults /dev/null
update-rc.d foo disable
fi
#v-
Marc Haber wrote:
On Mon, 28 Feb 2011 22:26:56 +0100, Arthur de Jong
adej...@debian.org wrote:
On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
Personally, I'd rather we didn't have them, as this is supposed to be
controlled by the rcN.d links and if that interface is too hard for
]] Christian Pohl
| Isn't update-rc.d the way to configure the rc.d scripts? Or am I
| old-fashioned.
The problem was at least until update-rc.d grew the «disable» argument
that disabling a daemon using update-rc.d was quite hard.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky
Tollef Fog Heen tfh...@err.no writes:
The problem was at least until update-rc.d grew the «disable» argument
that disabling a daemon using update-rc.d was quite hard.
update-rc.d foo disable is indeed convenient.
update-rc.d and policy-rc.d are currently two separate interfaces. If I
want to
]] Timo Juhani Lindfors
| Tollef Fog Heen tfh...@err.no writes:
| The problem was at least until update-rc.d grew the «disable» argument
| that disabling a daemon using update-rc.d was quite hard.
|
| update-rc.d foo disable is indeed convenient.
|
| update-rc.d and policy-rc.d are currently
On Tue, Mar 01, 2011 at 09:50:27AM +0100, Christian Pohl wrote:
Marc Haber wrote:
On Mon, 28 Feb 2011 22:26:56 +0100, Arthur de Jong
adej...@debian.org wrote:
On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
Personally, I'd rather we didn't have them, as this is supposed to be
On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek vor...@debian.org wrote:
Isn't update-rc.d the way to configure the rc.d scripts?
No, it's a way for *maintainer scripts* to manage init scripts.
Or am I old-fashioned.
You are using an interface that was never meant for administrator use.
On Tue, Mar 01, 2011 at 04:26:23PM +0100, Olaf van der Spek wrote:
On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek vor...@debian.org wrote:
Isn't update-rc.d the way to configure the rc.d scripts?
No, it's a way for *maintainer scripts* to manage init scripts.
Or am I old-fashioned.
You
On Tue, Mar 1, 2011 at 5:13 PM, Steve Langasek vor...@debian.org wrote:
On Tue, Mar 01, 2011 at 04:26:23PM +0100, Olaf van der Spek wrote:
On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek vor...@debian.org wrote:
Isn't update-rc.d the way to configure the rc.d scripts?
No, it's a way for
On Tue, Mar 01, 2011 at 05:19:37PM +0100, Olaf van der Spek wrote:
On Tue, Mar 1, 2011 at 5:13 PM, Steve Langasek vor...@debian.org wrote:
On Tue, Mar 01, 2011 at 04:26:23PM +0100, Olaf van der Spek wrote:
On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek vor...@debian.org wrote:
Isn't
On Tue, 2011-03-01 at 17:19 +0100, Olaf van der Spek wrote:
So what *is* the proper UI?
The sensible abstraction for this is 'service' - but it doesn't appear that
service has support for enable/disable yet :(
Do other distro's use service for this?
actually i think chkconfig is more
On Tue, Mar 1, 2011 at 7:25 PM, Sean Finney sean...@debian.org wrote:
well, for starters the interface sucks from a sysadmin point of view
compared to stuff like chkconfig/service. i also think that there's (a
perhaps shrunken, haven't checked in a while) set of things that you
just can't do
Sean Finney sean...@debian.org writes:
imho i think we need to step back and re-think the entire way we're
currently handling init scripts, both from the packaging point of view
and from the end-user/admin point of view.
Yes.
There are two issues here.
The short term issue is figuring out
Stig Sandbeck Mathisen s...@debian.org writes:
There are two issues here.
The short term issue is figuring out if the current practice of
DONT_DISABLE_ENABLEMENT=false and friends in /etc/default is something
we want to keep doing.
The long term issue is having a toolset, for the end user,
Olaf van der Spek wrote:
On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek vor...@debian.org wrote:
You are using an interface that was never meant for administrator use.
Nowadays there's an 'update-rc.d enable/disable', but even that, I think,
was intended to be a backend for the 'service'
Tollef Fog Heen wrote:
I think insserv makes it even more complicated, since I believe services
might
be pulled in, even if they're disabled. (Or it might be that insserv
just throws its hands into the air and tells you it doesn't know how to
do something the next time update-rc.d is run.)
]] Raphael Geissert
| Tollef Fog Heen wrote:
| I think insserv makes it even more complicated, since I believe services
| might
| be pulled in, even if they're disabled. (Or it might be that insserv
| just throws its hands into the air and tells you it doesn't know how to
| do something
On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
Personally, I'd rather we didn't have them, as this is supposed to be
controlled by the rcN.d links and if that interface is too hard for
people we should fix that rather than invent multiple ways of disabling
daemons, but the current
]] Arthur de Jong
Hi,
| On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
| Personally, I'd rather we didn't have them, as this is supposed to be
| controlled by the rcN.d links and if that interface is too hard for
| people we should fix that rather than invent multiple ways of
On Mon, 28 Feb 2011 22:26:56 +0100, Arthur de Jong
adej...@debian.org wrote:
On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
Personally, I'd rather we didn't have them, as this is supposed to be
controlled by the rcN.d links and if that interface is too hard for
people we should fix
On Saturday 26 February 2011 21.44:07 Tollef Fog Heen wrote:
I'd like us to decide on a policy about enable/disable flags in
/etc/default in general.
+1 on those who don't like to have them.
The init scripts (or whatever) need to
* provide a sane default for startup order
* allow users
]] Harald Dunkel
(This is from bug #602490, but it's more of a generic problem)
| Would it be possible to add an enable flag to
| /etc/default/nagios3 to control if the daemon is
| started at boot time?
I'd like us to decide on a policy about enable/disable flags in
/etc/default in general
to decide on a policy about enable/disable flags in
/etc/default in general. Either all daemons should have them or no
daemons should have them, and if we have them, I think we should have
the value in the default file should be standardised.
Personally, I'd rather we didn't have them
On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
I'd like us to decide on a policy about enable/disable flags in
/etc/default in general. Either all daemons should have them or no
daemons should have them, and if we have them, I think we should have
the value in the default file
On Feb 26, Tollef Fog Heen tfh...@err.no wrote:
Personally, I'd rather we didn't have them, as this is supposed to be
controlled by the rcN.d links and if that interface is too hard for
people we should fix that rather than invent multiple ways of disabling
daemons, but the current mess is,
53 matches
Mail list logo
