Marc Haber wrote:
> On Sun, 17 Aug 2014 23:14:33 -0500, Josh Triplett
> wrote:
> >Why a requirement to not improve upstream? Ideally, the Debian patches
> >for a piece of software should trend to zero over time, as fixes make
> >their way upstream.
>
> Imagine an upstream author having the coop
Marc Haber (2014-08-18):
> And others removed. Or do you actually claims that the systemd
> migration didn't actually break things? Not all of them, but a
> noticeable number.
(I don't think Russ claimed anything along those lines, no.)
Anyway: things get broken, bugs get reported, bugs get fixe
On Mon, 18 Aug 2014 09:31:37 -0700, Russ Allbery
wrote:
>could we tone down the assumption that people with
>differing preferences want to break everything you do? It's just a few
>additional options.
And others removed. Or do you actually claims that the systemd
migration didn't actually break
On Mon, Aug 18, 2014 at 09:31:37AM -0700, Russ Allbery wrote:
> More generally (and this part is not pointed at Thomas), I realize it's
> become de rigueur in any thread about systemd to reply to "hm, you could
> consider getting a dog" with "WHY DO YOU WANT TO KILL MY KITTENS?!?!?",
> but seriousl
On Sun, 17 Aug 2014, Marc Haber wrote:
> Please. The attitute of requiring Debian maintainers to modify
> upstream software instead of having simple two-line extension to an
> init script is really unfriendly. Why do only systemd friends keep
> recommending this?
Using my sysvinit hat, I've always
Thomas Goirand writes:
> On 08/18/2014 01:36 AM, Russ Allbery wrote:
>> The upstream source *can* be changed and improved for everyone.
> Truth, but not always practical. If I was going to fix all the defects
> of software I package, I don't think I'd have enough time to sleep even
> one hour pe
On 08/18/2014 01:36 AM, Russ Allbery wrote:
> The upstream source *can* be changed and improved for everyone.
Truth, but not always practical. If I was going to fix all the defects
of software I package, I don't think I'd have enough time to sleep even
one hour per night.
Thomas Goirand (zigo)
k is the best way to load some
> >> configuration.
> >>
> >> The ntopng daemon takes multiple interfaces in the format of multiple
> >> -i command-line options. For example.
> >> ntopng -i eth0 -i wlan0
> >>
> >> Currently the interfaces are s
On Sun, 17 Aug 2014 23:14:33 -0500, Josh Triplett
wrote:
>Why a requirement to not improve upstream? Ideally, the Debian patches
>for a piece of software should trend to zero over time, as fixes make
>their way upstream.
Imagine an upstream author having the cooperation level of the systemd
team
not the only distribution that will ever encounter this
> > problem. Rather than hacking around it downstream, why not fix it the
> > right way upstream? /etc/default almost always represents a
> > Debian-specific hack.
>
> Well, I do not see this as an upstream bug that needs
ings there.
>>
>> yes, that would be an option. I forgot to add the requirement "without
>> patching upstream code" :)
>
> Debian is not the only distribution that will ever encounter this
> problem. Rather than hacking around it downstream, why not fix it th
requirement "without
> patching upstream code" :)
Debian is not the only distribution that will ever encounter this
problem. Rather than hacking around it downstream, why not fix it the
right way upstream? /etc/default almost always represents a
Debian-specific hack.
Why a requirement
sms nowadays to enable/disable SysV init scripts
>>(and systemd service files).
>
> In my packages, I have usually not bothered with an ENABLED flag in
> /etc/default for a number of years, but I have not removed any ENABLED
> flags to keep backwards compatibility.
Yes, adding th
Josh,
On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett wrote:
> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
> settings there.
yes, that would be an option. I forgot to add the requirement "without
patching upstream code" :)
> 4) Teach ntopng to automatically detect the
ity is judged by how
well it meets the needs of users, which absolutely includes the requirement
that it *work smoothly across upgrades*.
It's one thing to discourage the use of /etc/default files, which I agree
are a lousy convention that should be deprecated. It's quite another to
On Sun, 17 Aug 2014 10:36:22 -0700, Russ Allbery
wrote:
>It's good to be aware of the option to improve the upstream source so that
>packaging it is easier and so that it works better for everyone with less
>configuration.
I find packaging easier when I work around a limitation in the
upstream so
Marc Haber writes:
> Josh Triplett wrote:
>> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> settings there.
>> 4) Teach ntopng to automatically detect the available network devices
>> on the system (including new ones that show up dynamically) and
>> automatically ha
Marco wrote:
>On Aug 17, Marc Haber wrote:
>
>> Please. The attitute of requiring Debian maintainers to modify
>> upstream software instead of having simple two-line extension to an
>> init script is really unfriendly. Why do only systemd friends keep
>> recommending this?
>Maybe because the other
On Sun, 17 Aug 2014 13:14:27 +0100, Simon McVittie
>if ! [ -e /etc/foo.conf ]
>then
>echo -n "(not starting, you need to create /etc/foo.conf)"
>return 0
>fi
if ! grep '^important-option' foo.conf;
looks like a rather common idiom.
Greetings
Marc
--
---
On Sun, 17 Aug 2014 13:48:44 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Aug 17, Marc Haber wrote:
>> Does Debian no longer care about easy updates, or have we accepted
>> that updating to jessie will be a nightmare anyway and recommend
>> reinstallation instead?
>Yes, I hate users and I want t
On 17/08/14 12:48, Marco d'Itri wrote:
> On Aug 17, Marc Haber wrote:
>> It is not
>> always possible to come with a working default configuration or to
>> build one in postinst.
>
> If unconfigured software really cannot fail cleanly then the package can
> install it without enabling the service
Hi,
>> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> settings there.
>> 4) Teach ntopng to automatically detect the available network devices on
>> the system (including new ones that show up dynamically) and
>> automatically handle all of them unless configured to do
Marc Haber writes:
> Quite a number of packages also refrain from starting the daemon on an
> unconfigured newly installed package until the user has configured it.
> I guess that this needs to be replaced "by native mechanisms (i.e.
> implemented as a patch to the upstream software)" as well? It
On Aug 17, Marc Haber wrote:
> Please. The attitute of requiring Debian maintainers to modify
> upstream software instead of having simple two-line extension to an
> init script is really unfriendly. Why do only systemd friends keep
> recommending this?
Maybe because the others do not care enough
On Aug 17, Marc Haber wrote:
> Does Debian no longer care about easy updates, or have we accepted
> that updating to jessie will be a nightmare anyway and recommend
> reinstallation instead?
Yes, I hate users and I want them to suffer.
> Quite a number of packages also refrain from starting the
On Aug 17, Ludovico Cavedon wrote:
> 2) instead of doing Exec=ntopng, Exec a script that does the mangling
> and then execs ntopng.
If you cannot improve the software enough then this is the best choice.
--
ciao,
Marco
signature.asc
Description: Digital signature
files).
In my packages, I have usually not bothered with an ENABLED flag in
/etc/default for a number of years, but I have not removed any ENABLED
flags to keep backwards compatibility.
Does Debian no longer care about easy updates, or have we accepted
that updating to jessie will be a nightmare anywa
On 17/08/14 10:38, Thomas Goirand wrote:
> I had the same problem as you describe above, even a bit more
> complicated because, in what we did, /etc/default/ sometimes
> doesn't exist (it's not mandatory in what we did).
EnvironmentFile takes precedence over Environment,
On Sun, 17 Aug 2014 12:05:13 +0200, Michael Biebl
wrote:
>But yeah, such wrapper scripts should be avoided if possible and native
>mechanisms used.
Having read quite of system docs in the last weeks to find a way to
key /etc/crypttab keyscript functionality back, I have found that
"using the nati
multiple interfaces in the format of multiple
>> -i command-line options. For example.
>> ntopng -i eth0 -i wlan0
>>
>> Currently the interfaces are stored in /etc/default/ntopng
>> INTERFACES="eth0 wlan0"
>>
>> and the sysv init script
ple
> -i command-line options. For example.
> ntopng -i eth0 -i wlan0
>
> Currently the interfaces are stored in /etc/default/ntopng
> INTERFACES="eth0 wlan0"
>
> and the sysv init script takes care of adding "-i" for each one of them.
>
> I would li
Am 17.08.2014 11:38, schrieb Thomas Goirand:
> How about teaching systemd that script is sometimes necessary? It's
> annoying to write a wrapper, because then, it does a fork to start the
> daemon, so the PID changes. Has this been reported upstream? If yes,
> what's upstream opinion about it?
I
ple
> -i command-line options. For example.
> ntopng -i eth0 -i wlan0
>
> Currently the interfaces are stored in /etc/default/ntopng
> INTERFACES="eth0 wlan0"
>
> and the sysv init script takes care of adding "-i" for each one of them.
>
> I would li
ample.
> ntopng -i eth0 -i wlan0
>
> Currently the interfaces are stored in /etc/default/ntopng
> INTERFACES="eth0 wlan0"
>
> and the sysv init script takes care of adding "-i" for each one of them.
>
> I would like to keep the sysv compatibility and
interfaces are stored in /etc/default/ntopng
INTERFACES="eth0 wlan0"
and the sysv init script takes care of adding "-i" for each one of them.
I would like to keep the sysv compatibility and do the same in systemd.
I tried in various ways, but the two solution I could think o
On Mon, 09 Dec 2013 11:27:37 -0800, Russ Allbery
wrote:
>If Policy says anything, I suspect we'll say that having a disable flag in
>/etc/default is considered harmful and packages should instead document
>that update-rc.d disable should be used for this purpose (and perhaps
>mig
it's a bug already, please open
> bugs in individual packages that have it (the original bug reporter
> noted mpd and icecast2).
If Policy says anything, I suspect we'll say that having a disable flag in
/etc/default is considered harmful and packages should instead document
that
system.
>
> When Debian no longer supports sysv init, a reply like this is
> acceptable. Currently it is not.
If we continue to support sysvinit (even if it's as one of several
alternatives), I think we should promote something like "update-rc.d
foo disable" as the "
control: reopen -1
control: reassign -1 debian-policy
thanks
Hi Bas,
On Montag, 9. Dezember 2013, Bas Wijnen wrote:
> That doesn't make it an unreasonable expectation. I've seen the same
> issue as well, and it always annoyed me. Why shouldn't we write this in
> policy? "It must be possible to
Processing control commands:
> reopen -1
Bug #601455 {Done: Holger Levsen } [general] can't stop
daemon using /etc/init.d/foo stop when disabled via /etc/default/foo
Bug #661496 {Done: Holger Levsen } [general] multiple,
annoyingly different ways to disable an init script
Bug reopened
> Date: Mon, 9 Dec 2013 15:27:11 +0100
> From: Holger Levsen
> To: 601455-d...@bugs.debian.org
> Subject: thats the way these init scripts are, use something else if you care
> about this
>
> I've decided to close this bug, as this "mis-feature" / bug is actually a
> main
> characteristic of s
/init.d/foo stop when disabled via
/etc/default/foo
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system admini
Processing commands for cont...@bugs.debian.org:
> clone 601455 -1
Bug#601455: multiple, annoyingly different ways to disable an init script
Bug 601455 cloned as bug 661496.
> retitle 601455 can't stop daemon using /etc/init.d/foo stop when disabled via
> /etc/default/foo
Bug #6
clone 601455 -1
retitle 601455 can't stop daemon using /etc/init.d/foo stop when disabled via
/etc/default/foo
quit
peter green wrote:
> regardless of any plan to discourage use of the /etc/default
> mechanism (I think removing it altogether is not really reasonable)
> I think th
Luckily vtun's RUN_SERVER option is
not an instance of the DISABLE pattern Mathias mentioned: it does not
work by exiting the init script early, and it does not prevent
stopping the server.
> regardless of any plan to discourage use of the /etc/default
> mechanism (I think removing it alto
Many packages seem to provide ENABLE/DISABLE variables in
/etc/default/foo, providing a confusing red herring for this
task --- a second method which does not work nearly as well,
as you pointed out
Though there are some situations where it is nessacery. Consider
vtund for example which has
Processing commands for cont...@bugs.debian.org:
> tags 601455 - patch
Bug #601455 [general] general: can't stop daemon using /etc/init.d/foo stop
when disabled via /etc/default/foo
Removed tag(s) patch.
> retitle 601455 multiple, annoyingly different ways to disable an init script
tags 601455 - patch
retitle 601455 multiple, annoyingly different ways to disable an init script
quit
Hi Mathias,
Mathias Kub wrote:
> When I try to stop a daemon after I disabled it in /etc/default/foo,
> I get an error-message that I can not stop it, because it is
> disabled.
>
&
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
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
>> >
ementing anything more than a "don't start any services in a
chroot" policy using this. And /etc/default/* isn't it; no consistent
variable naming, not implemented for all services (and shouldn't be), so
it's not scriptable, so it requires vi.
So the mv command abo
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
current practice of
> > DONT_DISABLE_ENABLEMENT=false and friends in /etc/default is something
> > we want to keep doing.
Actually I explicitly chose to not go down that path for
wesnoth-server. I settled for this approach:
dh_installinit -u 'stop 20 0 1 2 3 4 5 6 .'
This sets the symlinks
(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
e. i actually attempted to do this The Right Way once with nsca,
and it was really hard and involved lots of querying of invoke-rc.d.
On Tue, Mar 01, 2011 at 11:58:44PM +0100, Stig Sandbeck Mathisen wrote:
> The "short term" issue is figuring out if the current practice of
> DONT_
]] 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 havi
uring 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
starting and stopping services, enabling and disabling services when
booting, installing a
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
ime. I don't know whether switching to insserv made
>>things simpler in that regard though.
Isn't update-rc.d the way to configure the rc.d scripts? Or am I
old-fashioned.
My bits the /etc/default/scripts:
I would not use them to enable or disable deamons - only to "tune" the
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
es 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.)
| In general I don't like havin
> daemons, but the current mess is, well, a mess.
I would also love to have a way to easily configure which daemons should
be started at boot time. I don't know whether switching to insserv made
things simpler in that regard though.
In general I don't like having to mess with /etc/defa
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
On Sat, Feb 26, 2011 at 09:44:07PM +0100, Tollef Fog Heen wrote:
> ]] 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
&
1 - 100 of 139 matches
Mail list logo
