better make a standard for /etc/*/*_not_to_be_run
Dan Jacobson
$ ls /etc/*/*_not_to_be_run
/etc/apache/apache_not_to_be_run /etc/ssh/sshd_not_to_be_run
Any more?
Indeed, there are plenty of packages that I want installed, but that I use
only once a year or that are controlled by /etc/ppp/ip-*, thus I don't
want them started each boot.
zgrep not_to_be_run /usr/share/doc/debian-policy/*
shows nothing.
Hmmm, better make a standard for it quick. Should it be
/etc/$package/${package}_not_to_be_run
or
/etc/$package/${package}d_not_to_be_run
or some entirely different directory:
/etc/boot_no_run/ etc. etc.
After you set the policy, then those programs that want to give the
choice of starting at boot or not would at least have a standard place
to look for the answer.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Matt Zimmerman
> Just these so far?
> $ ls /etc/*/*_not_to_be_run
> /etc/apache/apache_not_to_be_run /etc/ssh/sshd_not_to_be_run
> Any more?
>
> Indeed, there are plenty of packages that I want installed, but that I use
> only once a year or that are controlled by /etc/ppp/ip-*, thus I don't
> want them started each boot.
rm -f /etc/rc?.d/S*package
--
- mdz
Colin Watson
> $ ls /etc/*/*_not_to_be_run
> /etc/apache/apache_not_to_be_run /etc/ssh/sshd_not_to_be_run
I don't think these should be standardized. If anything, sshd is likely
to disappear as soon as we get round to splitting the ssh package into
openssh-client and openssh-server or whatever.
--
Colin Watson [cjwa...@flatline.org.uk]
Alexander Schmehl
> > Indeed, there are plenty of packages that I want installed, but that I use
> > only once a year or that are controlled by /etc/ppp/ip-*, thus I don't
> > want them started each boot.
>
> rm -f /etc/rc?.d/S*package
might not survive a update of this package, update-rc.d (or
update-inetd) should be a better solution.
Yours sincerely
Alexander
Emile van Bergen
On Sun, Aug 10, 2003 at 07:30:17AM +0800, Dan Jacobson wrote:
> Just these so far?
> $ ls /etc/*/*_not_to_be_run
> /etc/apache/apache_not_to_be_run /etc/ssh/sshd_not_to_be_run
> Any more?
>
> Indeed, there are plenty of packages that I want installed, but that I use
> only once a year or that are controlled by /etc/ppp/ip-*, thus I don't
> want them started each boot.
>
> zgrep not_to_be_run /usr/share/doc/debian-policy/*
> shows nothing.
>
> Hmmm, better make a standard for it quick. Should it be
> /etc/$package/${package}_not_to_be_run
> or
> /etc/$package/${package}d_not_to_be_run
> or some entirely different directory:
> /etc/boot_no_run/ etc. etc.
>
> After you set the policy, then those programs that want to give the
> choice of starting at boot or not would at least have a standard place
> to look for the answer.
Whatever you suggest, it should of course be simple to implement. A
script doesn't know which package it belongs to, so a flag file name
something that contains $package may not be the best choice.
Personally, I like to think that /etc/rc?.d/* is the place to configure
such things. They aren't treated as conffiles for nothing, even more so
for the symlinks. If you don't want something to be run, move S20... to
skip/S20... A more indirect mechanism isn't strictly needed, IMHO.
However, if people think it's valuable, it should be a simple addition
that can be made to any init script. Eg.
script=`readlink -f $0 || echo $0`
[ -f /etc/skip/`basename $script` ] && exit 0
If the script is called from a symlink, the symlink is dereferenced
before testing if /etc/skip contains a file called the same as the
bare file name of the script itself, and if so, the script exits.
So, both /etc/rc2.d/S20lpd and /etc/rc0.d/K20lpd will exit if a file
called /etc/skip/lpd exists, because both of those files are symlinks
pointing to /etc/init.d/lpd.
Is that an idea?
The following line could be added to allow not just the admin, but also
programs to suppress each other's automatic startup and shutdown:
[ -f /var/skip/`basename $script` ] && exit 0
Cheers,
Emile.
--
E-Advies - Emile van Bergen em...@e-advies.nl
tel. +31 (0)70 3906153 http://www.e-advies.nl
Martijn van Oosterhout
I'd certainly hope it would. It's required by policy.
--
Martijn van Oosterhout <kle...@svana.org> http://svana.org/kleptog/
> "All that is needed for the forces of evil to triumph is for enough good
> men to do nothing." - Edmond Burke
> "The penalty good people pay for not being interested in politics is to be
> governed by people worse than themselves." - Plato
Matt Zimmerman
The man page for the former will explain why this is presently the correct
way to prevent a daemon from starting at boot.
Noah L. Meyerhans
> $ ls /etc/*/*_not_to_be_run
> /etc/apache/apache_not_to_be_run /etc/ssh/sshd_not_to_be_run
> Any more?
Ahh, no! Please! I never thought this was a nice way to disable
services. It just doesn't feel clean at all. I much prefer the way
packages like snmpd handle this. /etc/default/snmpd is sourced by the
startup script and sets a variable SNMPDRUN=yes. Change yes to no if
you don't want to run it.
OTOH, isn't this the kind of kludge that invoke-rc.d is supposed to fix?
This *does* exist in policy. From section 9.3.3.2:
The program invoke-rc.d is provided to make it easier for package
maintainers to properly invoke an initscript, obeying runlevel
and other locally-defined constraints that might limit a
package's right to start, stop and otherwise manage services.
This program may be used by maintainers in their packages'
scripts.
noah
Goswin von Brederlow
Esspecially since one might want to have a runlevel with networking
and ssh for normal use and one without networking for when one signs
packages with his usb stick. Or imilar cenarios.
MfG
Goswin
Bernd Eckenfels
> Personally, I like to think that /etc/rc?.d/* is the place to configure
> such things.
It is the place to configure such things. You just delete the S* link, and
the daemon will not be started.
If we need another solution, then I strongy encourage you to use a ".
/etc/package/config" method, where you have properties like
DAEMON_START=no
DAEMON_PARAM=-d
and so on.
Greetings
Bernd
--
(OO) -- Bernd_E...@Wendelinusstrasse39.76646Bruchsal.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Bernd Eckenfels
> /etc/default/snmpd is sourced by the
> startup script and sets a variable SNMPDRUN=yes.
I realy dont like abuse of a "default" directoryx for system local config.
Otherwise i like this schema, it is like irix was doing it, and as redhat is
doing it with sysconf.
And yes: it is not needed for the "run daemon" case.
Greetings
Bernd
--
(OO) -- Bernd_E...@Wendelinusstrasse39.76646Bruchsal.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Noah L. Meyerhans
> On Sun, Aug 10, 2003 at 01:00:50AM -0400, Noah L. Meyerhans wrote:
> > /etc/default/snmpd is sourced by the
> > startup script and sets a variable SNMPDRUN=yes.
>
> I realy dont like abuse of a "default" directoryx for system local config.
> Otherwise i like this schema, it is like irix was doing it, and as redhat is
> doing it with sysconf.
Yes, I'd really prefer to see /etc/default/ used for just that: package
*defaults*. The files in there should not be conffiles, and packages
should be free to overwrite files in there in the event that new
versions have different appropriate default values. Then provide a
similar mechanism for sysadmins to override those defaults.
The BSD systesms have /etc/default/rc.conf, for example, which is
sourced by system startup scripts to set some default shell values. A
sysadmin that doesn't want to change the defaults doesn't need to do
anything. If he does want to change the defaults, he simply needs to
put the variable assignment in /etc/rc.conf, which is also sourced by
the system startup scripts, but *after* /etc/default/rc.conf.
This is a very clean mechanism, and perhaps best of all it provides a
very clear distinction between the distribution defaults and the local
system defaults.
But, with invoke-rc.d and our runlevel structure, do we need to use such
a mechanism for determining whether or not to run a daemon?
noah
Joerg Wendland
> But, with invoke-rc.d and our runlevel structure, do we need to use such
> a mechanism for determining whether or not to run a daemon?
I don't think so. invoke-rc.d uses policy-rc.d which can tell if a
daemon may be started/stopped/restarted and so on. It just has to have
some kind of documentation or a default or example implementation. With
such we could emulate rc.config.
Cheers, Joerg
--
Joerg "joergland" Wendland
GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A F318 57A3 7FBD 51CF 8417
Michał Politowski
> On Sun, Aug 10, 2003 at 02:45:40AM +0200, Emile van Bergen wrote:
> > Personally, I like to think that /etc/rc?.d/* is the place to configure
> > such things.
>
> It is the place to configure such things. You just delete the S* link, and
> the daemon will not be started.
Except on upgrades, unfortunately.
http://bugs.debian.org/156161
--
Michał Politowski -- mp...@charybda.icm.edu.pl
Warning: this is a memetically modified message
Henrique de Moraes Holschuh
> > It is the place to configure such things. You just delete the S* link, and
> > the daemon will not be started.
>
> Except on upgrades, unfortunately.
> http://bugs.debian.org/156161
It is not broken at all. Due to the way sysv-rc works, no symlink at all
means "undefined state". If you go to a runlevel where something is started
(It has a S symlink), then back to a runlevel with no symlink, the service
is left alone (i.e. started).
Likewise, if you go to a runlevel where the service is stopped (K symlink),
then back to a runlevel where there is no sysmlink, the service is left
alone (i.e. stopped).
So, deleting a symlink to mean "do not start it" is an operator error. Put a
K symlink in there if you want the service to not be running on that
runlevel, OR switch to something less annoyingly error prone, such as
file-rc.
Anyway, no symlink = undefined behaviour. Actually adding that RC=104 in
the suggested patch in #156161 will cause trouble. querypolicy() (in
invoke-rc.d) will lose the information that we are dealing with undefined
behaviour.
BTW, if there is no policy-rc.d, undefined behaviour is set by the last
RC= line in querypolicy():
-8<-
else
if test x${RC} = x ; then
RC=104
fi
fi
-8<-
The default can be safely changed to "stop" by changing that to RC=101. I
see no problems with that at all, RC=104 is there just because I wanted no
further annoying complains that I was changing "the default Debian
behaviour", never mind it has always been a broken behaviour since day one
(i.e. before invoke-rc.d existed and packages started services every time
they were upgraded).
So please go on and change that to RC=101. Please do that in sync with
file-rc. Invoke-rc.d for file-rc needs exactly the same change.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Manoj Srivastava
> On Sun, Aug 10, 2003 at 04:40:50PM +0200, Bernd Eckenfels wrote:
>> On Sun, Aug 10, 2003 at 01:00:50AM -0400, Noah L. Meyerhans wrote:
>> > /etc/default/snmpd is sourced by the startup script and sets a
>> > variable SNMPDRUN=yes.
>>
>> I realy dont like abuse of a "default" directoryx for system local
>> config. Otherwise i like this schema, it is like irix was doing
>> it, and as redhat is doing it with sysconf.
> Yes, I'd really prefer to see /etc/default/ used for just that:
> package *defaults*. The files in there should not be conffiles, and
> packages should be free to overwrite files in there in the event
> that new versions have different appropriate default values. Then
> provide a similar mechanism for sysadmins to override those
> defaults.
In that case, why should the defaults not be in
/var/lib/defaults, or /usr/lib/defaults. and even
/usr/share/defaults?
I would not like to break the invariant that files under /etc
are under the users control, and user input is preserved.
There are two philosophies in tension here. One is that
presumes the user is not familiar with the program, and just wants ti
to "owrk", and the maintainer knows best how to make programs work
for such users.
The other is biased towards people who do know how their
stuff, and perhaps are using the programs in ways not immediately
obvious to the author/maintainer.
People espousing the former philosophy would like to ask the
suers a few questions, and then onwards take care of the nitty gritty
details of the configuration behind the scenes -- if one knows what
the user wants, one can provide it, and the end user need not be
bothered with the details.
I belong to the latter camp: I would prefer to be told about
any changes in configuration file syntax or preferred defaults (I
_like_ dpkg's conffile handling), but I would not like my values to
be just overridden. After all, rm does not warn me whenever I try
-rf ;-)
> The BSD systesms have /etc/default/rc.conf, for example, which is
> sourced by system startup scripts to set some default shell values.
> A sysadmin that doesn't want to change the defaults doesn't need to
> do anything. If he does want to change the defaults, he simply
> needs to put the variable assignment in /etc/rc.conf, which is also
> sourced by the system startup scripts, but *after*
> /etc/default/rc.conf.
> This is a very clean mechanism, and perhaps best of all it provides
> a very clear distinction between the distribution defaults and the
> local system defaults.
Hmm. Sounds like /usr/lib/defaults is a winner, here: the
admin merely has to populate /etc/defaults/foo with the proper values
taken from /usr/lib/defaults/foo (a comment at the top of an
initially empty /etc/defaulst/foo can tell the admin about system
defaults in /usr/lib/defaults/foo)
manoj
--
There are no winners in life, only survivors.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Michał Politowski
[...]
> It is not broken at all. Due to the way sysv-rc works, no symlink at all
> means "undefined state". If you go to a runlevel where something is started
> (It has a S symlink), then back to a runlevel with no symlink, the service
> is left alone (i.e. started).
>
> Likewise, if you go to a runlevel where the service is stopped (K symlink),
> then back to a runlevel where there is no sysmlink, the service is left
> alone (i.e. stopped).
>
> So, deleting a symlink to mean "do not start it" is an operator error. Put a
> K symlink in there if you want the service to not be running on that
> runlevel, OR switch to something less annoyingly error prone, such as
> file-rc.
Well, I must agree. The state is undefined, so it's probably better
to use explicit K links.
Still invoke-rc.d has to decide, and its current decision is inconsistent
with its documentation.
The documented behavior is slightly more convenient but actually I'm not sure
now this convenience is a good thing.
_Documenting_ how to properly disable a service and leaving the undefined
state to be a nuisance could be reasonable after all.
[...]
> So please go on and change that to RC=101. Please do that in sync with
> file-rc. Invoke-rc.d for file-rc needs exactly the same change.
If we are going to change the default for the undefined state to stop
the change in querypolicy is definitely better than the patch suggested by me.
Thomas Hood
> It is not broken at all. Due to the way sysv-rc works, no symlink
> at all means "undefined state". If you go to a runlevel where
> something is started (It has a S symlink), then back to a
> runlevel with no symlink, the service is left alone (i.e. started).
I agree that if there is no symlink for a runlevel then the
state of the service (running/stopped) should not be changed
on entering that runlevel.
The problem originally reported in #156161 is that invoke-rc.d
_starts_ a service in a runlevel which _lacks_ a symlink.
> Anyway, no symlink = undefined behaviour.
This contradicts what you said above: no symlink = no change.
--
Thomas
Dan Jacobson
# start_at_boot yes program
# start_at_boot no program
I suppose this would be implemented by a script calling update-rc.d.
The user must be able to use invoke-rc.d program at any time still.
P.S. I see /etc/init.d/ppp also has its own method to not start at boot.
Joey Hess
> In that case, why should the defaults not be in
> /var/lib/defaults, or /usr/lib/defaults. and even
> /usr/share/defaults?
>
> I would not like to break the invariant that files under /etc
> are under the users control, and user input is preserved.
Agreed. However, if I'd known how bds used /etc/defaults, I would not
have originally proposed the directory have that name. We *could* move
it to /etc/init.config/ or something.
However, I also like the concept of having a /usr/share/defaults (or
/lib/defaults or whatever) that has the big crufty files I rarely edit
(/etc/pcmcia/*.opts, for instance), and having things arranged so that
when I do need to override them I copy them to somewhere in /etc and
modify. Maes for smaller simplere /etc and maybe smaller root
filesystems.
No reason not to do both.
--
see shy jo
Henrique de Moraes Holschuh
> [...]
> > It is not broken at all. Due to the way sysv-rc works, no symlink at all
> > means "undefined state". If you go to a runlevel where something is started
> > (It has a S symlink), then back to a runlevel with no symlink, the service
> > is left alone (i.e. started).
> >
> > Likewise, if you go to a runlevel where the service is stopped (K symlink),
> > then back to a runlevel where there is no sysmlink, the service is left
> > alone (i.e. stopped).
> >
> > So, deleting a symlink to mean "do not start it" is an operator error. Put a
> > K symlink in there if you want the service to not be running on that
> > runlevel, OR switch to something less annoyingly error prone, such as
> > file-rc.
>
> Well, I must agree. The state is undefined, so it's probably better
> to use explicit K links.
> Still invoke-rc.d has to decide, and its current decision is inconsistent
> with its documentation.
Well, it can be argued that "invoke-rc.d itself will only pay attention to
the current runlevel, and block any tries to start an init script in a
runlevel it is not configured to be started at." means either "no S
symlink", or "a K symlink". The niceties of the sysv-rc system :-)
Powerful, but rather... picky.
As I said before, I'm happy with the RC=101 change. I didn't do it like
that right away because I didn't want extra opposition at the time.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh
> On Sun, 10 Aug 2003 16:46:26 -0300, Henrique de Moraes Holschuh wrote:
> > It is not broken at all. Due to the way sysv-rc works, no symlink
> > at all means "undefined state". If you go to a runlevel where
> > something is started (It has a S symlink), then back to a
> > runlevel with no symlink, the service is left alone (i.e. started).
>
> I agree that if there is no symlink for a runlevel then the
> state of the service (running/stopped) should not be changed
> on entering that runlevel.
That means the state of that service is UNDEFINED for that runlevel, if you
need to treat runlevels as atomic entities.
> The problem originally reported in #156161 is that invoke-rc.d
> _starts_ a service in a runlevel which _lacks_ a symlink.
The reason for which I explained already.
> > Anyway, no symlink = undefined behaviour.
>
> This contradicts what you said above: no symlink = no change.
"No change" means you need to know the previous status, if any, of ALL
services, across runlevel changes. This is NOT how sysv-rc works, so
"undefined" it is.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Marcelo E. Magallon
> I realy dont like abuse of a "default" directoryx for system local
> config. Otherwise i like this schema, it is like irix was doing it,
> and as redhat is doing it with sysconf.
Which is the thing I hate about IRIX and RH, you can't do this:
$ /etc/init.d/foo start
because /etc/default/foo says it should not be started.
--
Marcelo | "He says gods like to see an atheist around. Gives them
mmag...@debian.org | something to aim at."
| -- (Terry Pratchett, Small Gods)
Steve Lamb
"Marcelo E. Magallon" <mmag...@debian.org> wrote:
> $ /etc/init.d/foo start
> because /etc/default/foo says it should not be started.
So have a second one for user start? /etc/init.d/foo ustart Or maybe a
force option. -f?
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
| -- Lenny Nero - Strange Days
-------------------------------+---------------------------------------------
Marcelo E. Magallon
> On Sun, 10 Aug 2003 18:43:55 +0200
> "Marcelo E. Magallon" <mmag...@debian.org> wrote:
> > $ /etc/init.d/foo start
>
> > because /etc/default/foo says it should not be started.
>
> So have a second one for user start? /etc/init.d/foo ustart Or
> maybe a force option. -f?
Thereby making Debian even more different, no thanks.
Marcelo
Jamie Wilkinson
>We *could* move it to /etc/init.config/ or something.
If it has the same purpose as Red Hat's /etc/sysconfig then those of us who
look after machines with both distros would be ever grateful if the name is
consistent between them.
--
j...@debian.org http://people.debian.org/~jaq
Bob Proulx
> Which is the thing I hate about IRIX and RH, you can't do this:
>
> $ /etc/init.d/foo start
>
> because /etc/default/foo says it should not be started.
Let me second that problem but with a slightly different case. You
have a daemon running and want to stop it. You edit the file and
change the default setting. Then '/etc/init.d/foo stop' does not stop
the daemon because it is no longer configured.
Bob
Bernd Eckenfels
> Which is the thing I hate about IRIX and RH, you can't do this:
>
> $ /etc/init.d/foo start
>
> because /etc/default/foo says it should not be started.
Well, the start/nostart option is different from the other configuration. We
have already a way to prevent a init script from running, so you can
actually do "/etc/init.d/some-unlinked-script start" and what is good: the
script does not need to be changed to change some settings in there.
AFAIK RH/SuSE is also doing this on a different level, cant remeber about
irix, i think they had no sys v stile init scripts, at all.
Gruss
Bernd
--
(OO) -- Bernd_E...@Wendelinusstrasse39.76646Bruchsal.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Peter Karlsson
> If we need another solution, then I strongy encourage you to use a ".
> /etc/package/config" method, where you have properties like
Several packages include stuff like this in /etc/default/<packagename>, so
it seems there are several existing solutions to this problem. :-)
--
\\//
Peter - http://www.softwolves.pp.se/
I do not read or respond to mail with HTML attachments.
Bernd Eckenfels
> Several packages include stuff like this in /etc/default/<packagename>, so
> it seems there are several existing solutions to this problem. :-)
Yes, but /etc/default/ is totally the wrong directory. default is from
*BSD, where it is used to contain the defaults, not the local config. Other
Linux distributions do not use default, but something like sysconfig.
So: this is neighter common for linux nor the right usage of the dir.
Greetings
Bernd
--
(OO) -- Bernd_E...@Wendelinusstrasse39.76646Bruchsal.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Bruce Sass
> On Sun, 10 Aug 2003, Thomas Hood wrote:
> > On Sun, 10 Aug 2003 16:46:26 -0300, Henrique de Moraes Holschuh wrote:
> > > It is not broken at all. Due to the way sysv-rc works, no symlink
> > > at all means "undefined state". If you go to a runlevel where
> > > something is started (It has a S symlink), then back to a
> > > runlevel with no symlink, the service is left alone (i.e. started).
> >
> > I agree that if there is no symlink for a runlevel then the
> > state of the service (running/stopped) should not be changed
> > on entering that runlevel.
>
> That means the state of that service is UNDEFINED for that runlevel, if you
> need to treat runlevels as atomic entities.
>
> > The problem originally reported in #156161 is that invoke-rc.d
> > _starts_ a service in a runlevel which _lacks_ a symlink.
>
> The reason for which I explained already.
>
> > > Anyway, no symlink = undefined behaviour.
> >
> > This contradicts what you said above: no symlink = no change.
>
> "No change" means you need to know the previous status, if any, of ALL
> services, across runlevel changes. This is NOT how sysv-rc works, so
> "undefined" it is.
How should I handle these situations:
An X display manager is installed for those occasions when my
nieces and nephews drop by. I don't want to run kdm all the time and
doing "/etc/init.d/kdm start" when they arrive is a lot friendlier
than forcing them to use a text login and the commandline.
I keep GPG and ssh secrets in an encrypted directory (CFS) and only
"cattach" the dirs when they are needed. Startup of nfs-common,
nfs-kernel-server and cfsd is scripted and accessible from a
`shortcut' on the desktop; ditto the cattach commands.
My only beef with those setups is that kdm, nfs-*, and cfsd get
started when they get upgraded... having them as "K" links in rc2.d is
not correct because it is not the case that I don't want them to run,
I just don't want them to start automatically.
It would be nice if they were only started on upgrade if they are
already running.
- Bruce
Jeremy Hankins
> AFAIK RH/SuSE is also doing this on a different level, cant remeber about
> irix, i think they had no sys v stile init scripts, at all.
Irix does have sysv init scripts. Irix has a chkconfig script that
checks stuff stored in /etc/defaults. So in an init script you'll
typically find stuff like this:
IS_ON=/etc/chkconfig
SSHD=/usr/local/sbin/sshd
if $IS_ON verbose; then
ECHO=echo
else
ECHO=:
fi
case "$1" in
start)
if $IS_ON sshd && test -x $SSHD; then
Not that I recommend this, by any means; this is just a data point.
rc?.d is definitely the right way to control this stuff.
--
Jeremy Hankins <no...@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Peter Karlsson
> So: this is neighter common for linux nor the right usage of the dir.
Oh. I just picked up the practice from the other packages that did this.
Maybe I should change it (lyskom-server), then?
--
\\//
Peter - http://www.softwolves.pp.se/
I do not read or respond to mail with HTML attachments.
Guido Guenther
> On Mon, Aug 11, 2003 at 05:12:11PM +0100, Peter Karlsson wrote:
> > Several packages include stuff like this in /etc/default/<packagename>, so
> > it seems there are several existing solutions to this problem. :-)
>
> Yes, but /etc/default/ is totally the wrong directory. default is from
> *BSD, where it is used to contain the defaults, not the local config. Other
> Linux distributions do not use default, but something like sysconfig.
Then we use /etc/default different from the BSDs. Policy says that
/etc/default/ should be used to source configuration variables for init
scripts:
[..snip..]
changes. To ease the burden on the system administrator, such
configurable values should not be placed directly in the script.
Instead, they should be placed in a file in `/etc/default', which
typically will have the same base name as the `init.d' script. This
extra file should be sourced by the script when the script runs. It
[..snip..]
I agree that it's not the optimal place to store if a daemon should be
run or not (and that the name "default" is misleading) but it's probably
the best place until we have a policy-rc.d.
Regards,
-- Guido
Dan Jacobson
not" could be a dpkg-reconfigure question too?
I'm just worried that using methods the package maintainer never
considered the administrator would use in order to not have the
package start at boot, might break something.
Plus using a cold steely update-rc.d instead of a warm debconf dialog,
is just like using rm, it feels like we are doing surgery without a
licence -- the reassuring dialog that this is indeed how we are
supposed to make the package not start at boot.
Plus one doesn't have a universal interface, some must use
update-inetd, some update-rc.d .
Steve Greenland
> More foggy thoughts: maybe if a package "should be started at boot or
> not" could be a dpkg-reconfigure question too?
Oh, barf. For 99% of the installations, if you are installing a daemon,
you want it to run. Thus, the sensible default is to set it up to do so.
If you are among the 1% who installs it but for some reason doesn't want
it to run, then remove the start links, as has been documented forever.
That leaves the "restart on upgrade" problem, and we *have* a solution
for that (invoke-rc.d), and are just waiting for some one to implement
the remaining component (policy-rc.d).
So rather than wasting time coming up with new schemes, and dicking
around with yet more useless debconf questions, why not just implement
the existing, well-though-out scheme?
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Bernd Eckenfels
> Oh, barf. For 99% of the installations, if you are installing a daemon,
> you want it to run. Thus, the sensible default is to set it up to do so.
This may be true for non-standard and non-task selected daemons, but it is
for sure not true for any unexpected daemon invocatrion. Linux is not
Windows, I would expect all ports to be closed, not open.
Greetings
Bernd
--
(OO) -- Bernd_E...@Wendelinusstrasse39.76646Bruchsal.de --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Bob Hilliard
> Oh, barf. For 99% of the installations, if you are installing a daemon,
> you want it to run. Thus, the sensible default is to set it up to do so.
Many packages can run as a daemon, but can run equally well when
invoked on the command line. For instance most (all?) MTAs run as
daemons by default. I never knowingly allow an MTA to run as a daemon
on my machines, but have been surprised at times to find one running.
Regards,
Bob
--
_
|_) _ |_ Robert D. Hilliard <hill...@debian.org>
|_) (_) |_) 1294 S.W. Seagull Way <b...@bobhilliard.net>
Palm City, FL 34990 USA GPG Key ID: 390D6559
Thomas Hood
issue raised in #156161. Toward that end I offer the following
interpretation of what has been said and finally a proposal.
The original question was about how to prevent services from
being started. Some packages employ a mechanism (a flag file,
or an environment variable set it in an /etc/default/ file)
other than the standard "rc" mechanism for switching services on
and off.
The brief reply to this was: Don't do that. The standard mechanism
for enabling and disabling services in runlevels is update-rc.d,
so please use that. This answer is basically right. If I run
"/etc/init.d/foo start" then foo should start. Period.
We have to accept, however, that people want, in addition to the
rc system, a simple way globally to enable and disable a given
service. The reason is that if one decides to disable a service
by setting all its rc?.d symlinks to K then he loses the infor-
mation about what those symlinks should be named when the service
is reënabled. Such a mechanism has been wished for in #67095 and
#123446 among other places. Perhaps those wishes should be
fulfilled and something should be written to make it easy for the
admin to disable and enable a service without destroying the rc
symlink farm information. Such a utility would use update-rc.d
to make changes (as required by policy) but would remember how
things were set up before the service was disabled so that that
situation could easily be restored.
Whether and how that wish is granted is not my main concern here.
What I would like to know is whether we can agree to enhance the
rc system by defining what happens when there is neither a start
nor a stop symlink for a service in a given runlevel.
Henrique de Moraes Holschuh and I discussed this point earlier
but we didn't see eye to eye because we were approaching it
with different assumptions about what the right behavior is.
HdMH assumed that all services are supposed to be controlled by
the rc system which requires that there be either an S or a K
symlink for each service in every runlevel directory. If there
is neither an S nor a K symlink for a service in a particular
directory then this is operator error and the behavior of the
system is "undefined". It follows that it isn't a bug that
invoke-rc.d starts the service. I was approaching the issue
under the assumption that if there is neither an S nor a K
symlink for a service in a particular runlevel directory then
that means that the rc system should not change the state of
the service but should leave a running service running and a
stopped service stopped. #156161 was originally rated as a
bug report based on this assumption.
I am now willing to grant that HdMH is right and that
_currently_ the behavior of the rc system is not defined if
there is neither an S nor a K symlink for a service in a given
runlevel directory. My proposal is that the behavior of the
rc system _be_ defined such that it works the way I assumed it
was supposed to work, i.e., such that if there is neither an S
nor a K symlink for a service in a particular runlevel
directory then that service is to be neither started nor stopped
on entering that runlevel.
The advantage this specification would have is that it would
allow maintainers to install services and initscripts that are
not by default under the control of the rc system but under the
control of the administrator who can run the initscript with
"start" and "stop" arguments. Changing runlevel would neither
start nor stop these services unless the administrator chose to
put the service under the control of the rc system by setting up
symlinks in the runlevel directories. The absence of S and K
symlinks would mean "manual". I have downgraded #156161 to a
wish for this enhancement. If a utility was written to make
it more convenient to disable and enable a service, as discussed
above, then one could add a "manual" state (no symlinks) to
the "disabled" (all K symlinks) and "enabled" (not all K symlinks)
states.
Is this a good idea? If not, I would be interested to know where
the problems lie.
--
Thomas Hood
Thomas Hood
issue raised in #156161. Toward that end I offer the following
we can agree to implement the reinterpreted #156161.
The original question was about how to prevent services from
being started. Some packages employ a mechanism (a flag file,
or an environment variable set it in an /etc/default/ file)
other than the standard "rc" mechanism for switching services on
and off.
The blunt reply to this was: Don't do that. The standard mechanism
for enabling and disabling services in runlevels is update-rc.d,
so please use that. This answer is basically right. If I run
"/etc/init.d/foo start" then foo should start.
We have to accept, however, that people want, in addition to the
rc system, a simple way globally to enable and disable a given
service. One reason is that if one decides to disable a service
by setting all its rc?.d symlinks to K then he loses the infor-
mation about what those symlinks should be named when the service
is reënabled. Such a mechanism has been wished for in #67095 and
#123446 among other places. Perhaps those wishes should be
fulfilled and something should be written to make it easy for the
admin to disable and enable a service without destroying the rc
symlink farm information. Such a utility would use update-rc.d
to make changes (as required by policy) but would remember how
things were set up before the service was disabled so that the
former situation could be easily restored.
Whether and how that wish is granted is not my main concern here.
What I would like to know is whether we can agree to enhance the
rc system by defining what happens when there is neither a start
nor a stop symlink for a service in a given runlevel.
Henrique de Moraes Holschuh and I discussed this point earlier
but we didn't see eye to eye because we were approaching it
with different assumptions about what the right behavior is.
HdMH assumed that all services are supposed to be controlled by
the rc system which requires that there be either an S or a K
symlink for each service in every runlevel directory. If there
is neither an S nor a K symlink for a service in a particular
directory then this is operator error and the behavior of the
system is "undefined". It follows that it isn't a bug that
invoke-rc.d starts the service. I was approaching the issue
under the assumption that if there is neither an S nor a K
symlink for a service in a particular runlevel directory then
that means that the rc system should not change the state of
the service but should leave a running service running and a
stopped service stopped. #156161 was originally rated as a
bug report based on this assumption. Bug #197858 was also
submitted based on that assumption.
I am now willing to grant that HdMH is right and that
_currently_ the behavior of the rc system is not defined if
there is neither an S nor a K symlink for a service in a given
runlevel directory. My proposal is that the behavior of the
rc system _be_ defined such that it works the way I assumed it
was supposed to work, i.e., such that if there is neither an S
nor a K symlink for a service in a particular runlevel
directory then that service is to be neither started nor stopped
on entering that runlevel.
The advantage this specification would have is that it would
allow maintainers to install services and initscripts that are
not by default under the control of the rc system but under the
control of the administrator, who can run the initscript with
"start" and "stop" arguments. Changing runlevel would neither
start nor stop these services unless the administrator chose to
put the service under the control of the rc system by setting up
symlinks in the runlevel directories. The absence of S and K
symlinks would mean "manual". If a utility was written to make
it more convenient to disable and enable a service, as discussed
above, then one could add a "manual" state (no symlinks) to
the "disabled" (all K symlinks) and "enabled" (not all K symlinks)
states. I have downgraded #156161 to a wish that the rc system
be specified in this way.
Can we agree that this a good idea? If not, I would be interested