Bug#102210: marked as done (dpkg: starts up service even if service is disabled in current runlevel)
Your message dated Thu, 11 Mar 2004 14:31:01 +0100
with message-id <1079011861.3962.1266.camel@localhost>
and subject line Not a bug in dpkg
has caused the attached Bug report 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 administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
Received: (at submit) by bugs.debian.org; 25 Jun 2001 12:02:54 +0000
>From firstname.lastname@example.org Mon Jun 25 07:02:54 2001
Received: from (marvin.emdete.de) [::ffff:18.104.22.168]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 15EV4i-0000pH-00; Mon, 25 Jun 2001 07:02:51 -0500
Received: by marvin.emdete.de (Postfix, from userid 1000)
id AAEAE9D10; Mon, 25 Jun 2001 13:53:41 +0200 (CEST)
From: M.Dietrich <email@example.com>
Subject: dpkg: starts up service even if service is disabled in current runlevel
X-Mailer: bug 3.3.9
Date: Mon, 25 Jun 2001 13:53:41 +0200 (CEST)
i don't know if this is a dpkg-related wish: i install a lot of
services on my notebook which i normaly don't use. i remove the links
from /etc/rc2.d/ for those service that i don't need. if i want one of
those i start those by hand or change the runlevel. if i do an upgrade
of the system dpkg (or the scripts of the packages) start up those
serveces regardless if the links a present or not for the current
runlevel which opens up security holes in my opinion. should those
scripts look at the current runlevel and into the corresponding
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux marvin 2.4.5-686 #1 Sun May 27 18:03:50 EST 2001 i686 unknown
Versions of the packages dpkg depends on:
ii libc6 2.2.3-6 GNU C Library: Shared libraries and Timezone
ii libncurses5 5.2.20010318-2 Shared libraries for terminal handling
ii libstdc++2.10- 2.95.4-0.01060 The GNU stdc++ library
Received: (at 102210-done) by bugs.debian.org; 11 Mar 2004 13:31:42 +0000
>From firstname.lastname@example.org Thu Mar 11 05:31:42 2004
Received: from mars.mj.nl [22.214.171.124]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1B1QHm-0004qO-00; Thu, 11 Mar 2004 05:31:42 -0800
Received: (qmail 27976 invoked from network); 11 Mar 2004 13:31:11 -0000
Received: from 81-91-5-95-customer.mjdsl.nl (HELO thanatos) (126.96.36.199)
by www.mj.nl with SMTP; 11 Mar 2004 13:31:11 -0000
Received: from localhost (localhost [127.0.0.1])
by thanatos (Postfix) with ESMTP id EFEA010D712
for <email@example.com>; Thu, 11 Mar 2004 14:31:01 +0100 (CET)
Subject: Not a bug in dpkg
From: Thomas Hood <firstname.lastname@example.org>
X-Mailer: Ximian Evolution 1.4.5
Date: Thu, 11 Mar 2004 14:31:01 +0100
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_08
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=0.0 required=4.0 tests=none autolearn=no
> i don't know if this is a dpkg-related wish: i install a lot of
> services on my notebook which i normaly don't use. i remove the links
> from /etc/rc2.d/ for those service that i don't need.
That is the wrong thing to do. To disable a service in runlevel x
you must replace any S sumlink in /etc/rcx.d/ with a K symlink.
Often the sequence number of the K symlink is 100 minus the
sequence number of the S symlink.
> if i want one of
> those i start those by hand or change the runlevel. if i do an upgrade
> of the system dpkg (or the scripts of the packages) start up those
> serveces regardless if the links a present or not for the current
> runlevel which opens up security holes in my opinion.
This isn't dpkg's fault. Debian just doesn't support "manual"
control of services. Adding support requires modifying invoke-rc.d
and adding "try-restart" support to service initscripts.
Thomas Hood <email@example.com>