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,
]] 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 use
Raphael Geissert 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 initscripts,
wont insserv
Tollef Fog Heen 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 not
clear the
Michael Biebl 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 /etc/rc3.d/K02avahi-
Am 20.03.2011 16:14, schrieb Timo Juhani Lindfors:
> Serafeim Zanikolas 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-r
Serafeim Zanikolas 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, renaming init sc
On Thu, Mar 10, 2011 at 12:59:46AM +0200, Timo Juhani Lindfors wrote:
> Serafeim Zanikolas 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.
Serafeim Zanikolas 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, email to debian-d
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
> > p
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 de
Drake Wilson writes ("Re: enable/disable flags in /etc/default"):
> Quoth Bob Proulx , 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
On Thu, Mar 3, 2011 at 7:25 AM, Tollef Fog Heen 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
just do a dae
]] 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 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 tim
...
Before someone starts to nitpick it and distract from the real content:
* Gerfried Fuchs [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
>
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 [2011-03-02 14:47:22 CET]:
> Actually I explicitly chose to not
]] Drake Wilson
| (Sorry for the duplicate, Bob; forgot to send to list first time.)
|
| Quoth Bob Proulx , 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 vari
(Sorry for the duplicate, Bob; forgot to send to list first time.)
Quoth Bob Proulx , 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
segments of t
Stig Sandbeck Mathisen wrote:
> Currently, our packaged services start automatically, unless explicitly
> disabled in /etc/default/, or by missing configuration.
Having daemons started automatically at installation time is a very
nice feature of Debian IMNHO. And by comparison it really annoys m
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
>> >
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
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)
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
>
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
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 writes:
> > The "short term" issue is figuring out if the current practice of
> > DONT_DISABLE_ENAB
(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 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 fe
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 handle
]] 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 somethin
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
Olaf van der Spek wrote:
> On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek 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' command.
>
> So
Stig Sandbeck Mathisen 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, for
>
Sean Finney 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 if the current
On Tue, Mar 1, 2011 at 7:25 PM, Sean Finney 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 with update-rc.
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
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 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 wrote:
> >> >> Isn't update-rc.d the way to configu
On Tue, Mar 1, 2011 at 5:13 PM, Steve Langasek 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 wrote:
>> >> Isn't update-rc.d the way to configure the rc.d scripts?
>
>> > No, it's a way for *maintainer scripts* to mana
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 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 us
On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek 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.
> Nowadays th
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
> > 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
> >>> con
]] Timo Juhani Lindfors
| Tollef Fog Heen 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 separat
Tollef Fog Heen 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 make sure tha
]] "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 abo
Marc Haber wrote:
> On Mon, 28 Feb 2011 22:26:56 +0100, Arthur de Jong
> 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
On Mon, 28 Feb 2011 22:26:56 +0100, Arthur de Jong
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 that rather t
]] 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 di
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 curren
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
On Feb 26, 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 mess is, well, a mes
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
gt; | started at boot time?
>
> 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 should be
]] 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
/et
53 matches
Mail list logo
