3 ms·

Surely not all daemons start automatically. Some of them source files from /etc/default, with an "off" setting per default. And there are plenty of daemons for

Surely not all daemons start automatically. Some of them source files from /etc/default, with an "off" setting per default. And there are plenty of daemons for which it makes sense to start automatically (eg, installing pulseaudio and expecting it to work without having to figure out how to configure it is not an unreasonable expectation). So maybe: - more daemons (eg, puppet) ought to be "off" per default when it doesn't make sense - apt-get should provide a switch to prevent newly-added daemons from starting, which could be used by provisioning systems But saying that "daemons should never start at install" is silly.

duskwuff 12y ago
The latter is precisely what the /usr/sbin/policy-rc.d business that this post is talking about is for.
- erikano 12y ago
  This appears to me to be correct. Found a file /usr/share/doc/sysv-rc/README.policy-rc.d.gz on my system where it says: > POLICY-RC.D Policy layer (/usr/sbin/policy-rc.d) interface: > Most Debian systems will not have this script as the need for a policy layer is not very common. Most people using chroot jails just need an one-line script which returns an exit status of 101 as the jailed /usr/sbin/policy-rc.d script. I think, however, that the point that the parent comment was trying to make was that it'd be convenient if this was a switch to apt-get. After all, if you are just looking to install one additional daemon on a running system, it'd be a whole lot easier if you could: # apt-get install --no-start-daemon example than to have to activate a policy script which you might forget to remove or deactivate. However, in the file I mentioned above, the next line says: > The /usr/sbin/policy-rc.d file must be managed through the alternatives system (/usr/sbin/update-alternatives) by any packages providing it. So maybe one solution is to create your own script to manage it. In fact, your script could even be a wrapper for apt-get. To be totally transparent in day-to-day use, you could then make apt-get be an alias for your wrapper script. Your wrapper then: 1. Activates the policy. 2. Calls the real apt-get. 3. Deactivates the policy.
serf 12y ago
"daemons without sane defaults should never start at install" It's silly that certain daemons check for a default settings file to decide if an execution is permitted rather than skipping that logic and defaulting the service off until either user intervention provides sane operating defaults, or the defaults are known to be sane otherwise. I agree that a switch should be included with the package managers, but I also believe that the package managers should look for a switch from the package maintainers as well. "areDefaultsSane = 0" should require user intervention to start after install and would be intended for things like insecure network daemons or daemons that control thermals/power/otherwiseImportantThings, whereas things that flagged "areDefaultsSane" as true would be started without intervention, this being intended for things like pulse. things like thinkfan (a cpu/fan manager for linux) include "run_at_start = False" in the /etc/default file and things like that, but it feels woefully inadequate to rely on the package itself to check for something potentially mean when the environment could handle it in a standardized way, perhaps within whatever metadata is included in the deb file rather than the packages' included /etc/default/? (disclaimer: I don't know how deb files are put together)
- icebraining 12y ago
  A file in /etc/default is a standardized way. It's part of the Debian Policy. Putting it in the metadata wouldn't help, since the point is to be mutable, that is, to allow the admin to switch the default to "run on startup".
stormbrew 12y ago
AFAIK it is Debian (and Ubuntu) policy for all packages to auto start services. And it is also quite difficult to pre-set package config files before installing, especially if you want to script it with a configuration manager like puppet. I can't recall ever seeing a package in the official repositories for which this is not the case, and it is a real and genuine pain point in using Debian as a server.
- deleted 12y ago
  [deleted]

duskwuff 12y ago

The latter is precisely what the /usr/sbin/policy-rc.d business that this post is talking about is for.

erikano 12y ago
This appears to me to be correct. Found a file /usr/share/doc/sysv-rc/README.policy-rc.d.gz on my system where it says: > POLICY-RC.D Policy layer (/usr/sbin/policy-rc.d) interface: > Most Debian systems will not have this script as the need for a policy layer is not very common. Most people using chroot jails just need an one-line script which returns an exit status of 101 as the jailed /usr/sbin/policy-rc.d script. I think, however, that the point that the parent comment was trying to make was that it'd be convenient if this was a switch to apt-get. After all, if you are just looking to install one additional daemon on a running system, it'd be a whole lot easier if you could: # apt-get install --no-start-daemon example than to have to activate a policy script which you might forget to remove or deactivate. However, in the file I mentioned above, the next line says: > The /usr/sbin/policy-rc.d file must be managed through the alternatives system (/usr/sbin/update-alternatives) by any packages providing it. So maybe one solution is to create your own script to manage it. In fact, your script could even be a wrapper for apt-get. To be totally transparent in day-to-day use, you could then make apt-get be an alias for your wrapper script. Your wrapper then: 1. Activates the policy. 2. Calls the real apt-get. 3. Deactivates the policy.

serf 12y ago

"daemons without sane defaults should never start at install" It's silly that certain daemons check for a default settings file to decide if an execution is permitted rather than skipping that logic and defaulting the service off until either user intervention provides sane operating defaults, or the defaults are known to be sane otherwise. I agree that a switch should be included with the package managers, but I also believe that the package managers should look for a switch from the package maintainers as well. "areDefaultsSane = 0" should require user intervention to start after install and would be intended for things like insecure network daemons or daemons that control thermals/power/otherwiseImportantThings, whereas things that flagged "areDefaultsSane" as true would be started without intervention, this being intended for things like pulse. things like thinkfan (a cpu/fan manager for linux) include "run_at_start = False" in the /etc/default file and things like that, but it feels woefully inadequate to rely on the package itself to check for something potentially mean when the environment could handle it in a standardized way, perhaps within whatever metadata is included in the deb file rather than the packages' included /etc/default/? (disclaimer: I don't know how deb files are put together)

icebraining 12y ago
A file in /etc/default is a standardized way. It's part of the Debian Policy. Putting it in the metadata wouldn't help, since the point is to be mutable, that is, to allow the admin to switch the default to "run on startup".

stormbrew 12y ago

AFAIK it is Debian (and Ubuntu) policy for all packages to auto start services. And it is also quite difficult to pre-set package config files before installing, especially if you want to script it with a configuration manager like puppet. I can't recall ever seeing a package in the official repositories for which this is not the case, and it is a real and genuine pain point in using Debian as a server.

deleted 12y ago
[deleted]