Re: How to prevent daemons from starting at boot after update?
On 27/11/12 23:47, Adrian Fita wrote:
> On 27/11/12 23:19, Michael Biebl wrote:
>> On 27.11.2012 20:52, Adrian Fita wrote:
>>
>>> I just did a cups package update (yes, I'm running Debian unstable) and
>>> noticed that the cups daemon was started after the upgrade. And indeed,
>>> looking in /var/lib/dpkg/info/cups.postinst, the daemon is started with
>>> "invoke-rc.d cups start" after every installation. This means that even
>>> tho' I have disabled cups from starting at boot with "update-rc.d cups
>>> disable", it will get started after an update/package reinstallation,
>>
>> Not correct. A sysv init script which has been disabled via
>> "update-rc.d <service> disable" won't be started by
>> "invoke-rc.d <service> start"
>>
>> Not saying that there might actually be a bug in cups' postinst script,
>> but invoke-rc.d itself respects the enable/disable state.
>
> Hmm. Interesting.
> - line 192 in /var/lib/dpkg/info/cups.postinst contains "invoke-rc.d
> cups start || exit $?", so no special parameter is passed to invoke-rc.d
> - running "invoke-rc.d cups start" manually, as root, from console,
> starts cups
> - my current runlevel is 2, I made sure that cups is indeed disabled:
> /etc/rc2.d/K02cups
> - looking directly in the file /usr/sbin/invoke-rc.d, I see that there
> is some mention of runlevels, but I couldn't figure out what invoke-rc.d
> does with them...
>
> So, what am I doing wrong?
I tried with atop as well:
- /var/lib/dpkg/info/atop.postinst contains "invoke-rc.d atop start ||
exit $?" on line 13
- running "invoke-rc.d atop start" manually, as root, from console,
starts atop
- I made sure that atop is indeed disabled: /etc/rc2.d/K01atop
But, the invoke-rc.d manual says that it honors the current runlevel:
--->8--
invoke-rc.d itself only pays attention to the current runlevel; it
will block any attempts to start a service in a runlevel in which the
service is disabled. Other policies are implemented with the use of the
policy-rc.d helper, and are only available if /usr/sbin/policy-rc.d is
installed in the system.
--->8--
So it seems that there's something wrong on my system. But what? Or it
could be a bug in the invoke-rc.d version in unstable.
--
Adrian Fita
Reply to: