I recently started seeing
insserv: warning: current stop runlevel(s) (0 1 6) of script `cron' overwrites defaults (1).
upon aptitude update, in the experimental distribution. Google finds
some too:
http://www.google.com/search?q=%22insserv:+warning:+current+stop+runlevel(s)+(0+1+6)+of+script+%60cron%27+overwrites+defaults+(1).%22

So the LSB headers in /etc/init.d/cron say that (1) is the default
level, but your /etc/rc?.d directories contain symlinks for (0 1 6).

These symlinks probably came from an older cron installation (pre-101),
is it possible that you've been using (+upgrading) that system since then?

CK> So the LSB headers in /etc/init.d/cron say that (1) is the default
CK> level, but your /etc/rc?.d directories contain symlinks for (0 1 6).

# Default-Start:     2 3 4 5
# Default-Stop:      1
$ /usr/sbin/sysv-rc-conf --list cron
cron         0:off      1:off   2:on    3:on    4:on    5:on    6:off

CK> These symlinks probably came from an older cron installation (pre-101),
CK> is it possible that you've been using (+upgrading) that system since then?

All I know is that I've used Debian since 2000, 2005, and 2009 on my
three computers.

How could /etc/init.d/cron never be updated during apt-get upgrade?
Or shouldn't changes like this be presented to the user with a dialog
asking what to do, "accept the maintainers change, or keep my own
version, etc.?"

Somebody, not me, blew it, by not keeping components up to date?!?

That's probably the cause then.

For valid reasons, -101 removed levels 0 and 6 from the default
runlevels. This only affected new installations, existing symlinks were
not touched to preserve possible local changes.

See update-rc.d(8), section "INSTALLING INIT SCRIPT LINKS" for a rationale.

Not for runlevel symlinks.

See above.

Apart from your bug report, we were previously aware of the insserv
issue. I'm still contemplating a solution for this in postinst, but the
problem is that there is no easy way to determine whether the current
runlevels were set by an older cron or by the system administrator. Even
on post-101 installs, the administrator might have manually set (0 1 6)
after the package set (1), so we cannot just delete the links if they
are present.

It is also worth to note that this is merely a cosmetic issue, with
absolutely no side effects (which is why I left it wishlist). If you
want to get rid of the warning, just do

# rm -f /etc/rc{0,6}.d/K??cron

on the affected systems.

CK> Apart from your bug report, we were previously aware of the insserv
CK> issue. I'm still contemplating a solution for this in postinst, but the
CK> problem is that there is no easy way to determine whether the current
CK> runlevels were set by an older cron or by the system administrator. Even
CK> on post-101 installs, the administrator might have manually set (0 1 6)
CK> after the package set (1), so we cannot just delete the links if they
CK> are present.

A debconf item or even file that says "asked them what to do now that we
changed things" perhaps (yuck)?

CK> It is also worth to note that this is merely a cosmetic issue, with
CK> absolutely no side effects (which is why I left it wishlist). If you
CK> want to get rid of the warning, just do

Things shouldn't become different on different machines over time.

CK> # rm -f /etc/rc{0,6}.d/K??cron

Never touch them by hand, Mom says. However, I find, and am reporting
bugs, that both sysv-rc-conf and update-rc.d, have no way, to say "when
I say defaults, I would please like you to use the defaults as found in
the LSB headers for the particular service, and not the hardwired 2345
defaults as found in your program." "Or a new lsb-defaults parameter."

So referring to /var/lib/dpkg/info/cron.postinst I did
# update-rc.d cron remove
# update-rc.d cron start 89 2 3 4 5 . stop 11 1 .
Which makes
# ls -1 /etc/rc?.d/???cron
/etc/rc1.d/K01cron
/etc/rc2.d/S02cron
/etc/rc3.d/S02cron
/etc/rc4.d/S02cron
/etc/rc5.d/S02cron
which I suppose will do.

<--  snip  -->

cron (3.0pl1-101) unstable; urgency=low

  [ Christian Kastner ]
...
  * debian/cron.init:
    - Changed Default-Stop from (1) to (empty). rc0 and rc6 were removed in
      3.0pl1-101 because the stop action -- sending SIGTERM/SIGKILL to cron
      on shutdown/reboot -- was redundant. This, however, also applies to
      rc1, because killprocs will do that for us.
  * debian/postinst:
...
    - Removed last remaining stop action (for rc1) from upate-rc.d (see above)
...

<--  snip  -->


Looking through cron bugs, I find #583714, and that contains:

<--  snip  -->

Apart from your bug report, we were previously aware of the insserv
issue. I'm still contemplating a solution for this in postinst, but the
problem is that there is no easy way to determine whether the current
runlevels were set by an older cron or by the system administrator. Even
on post-101 installs, the administrator might have manually set (0 1 6)
after the package set (1), so we cannot just delete the links if they
are present.

<--  snip  -->


My impression is that there are two problems:
- There is confusion whether a package can remove links when the
  defaults change and
- there is the question how to fix it in the many packages where it is
  currently wrong after upgrading.

cu
Adrian