Bug 682861

not the fault of smpppd nor SuSEfirewall2. try
# grep Default-Start.*4 /etc/init.d/*
to find the culprit

Thanks for the hints:

-> grep Default-Start.*4 /etc/init.d/*
 yielded only skeleton.compat

moving this apart (i. e. removing the runlevel 4 entry and deleting the backup file yields:

djunix:/etc/init.d # grep Default-Start.*4 /etc/init.d/*
djunix:/etc/init.d # 

i. e. nothing. Changing the entry 

# Default-Start:  3 5
# Default-Stop:   0 1 2 6

to match network, i. e. removing "2" from the Default-Start list changed nothing.

Still the error as described in #1

This is in contrast to what happens on my netbook, there I got a similar error at the beginning (but without reference to any runlevel 4 issue):

insserv: FATAL: service network is missed in the runlevels 2 to use service smpppd.

If I remove runlevel 2 from smpppd, insserv works on my Netbook for smpppd, but does not on my "regular" PC, the message remains "as is". By the way, on the netbook there is no impact of the "runlevel 4" entry within skeleton.compat

Any further ideas?

Thank you for looking into this,
take care 



Dieter Jurzitza

looks like fallout from bug 682861. network used to be enabled in runlevel 2 not no longer is. On update installations it stays enabled in runlevel 2. Therefore enabling smpppd only fails on new installation. Smpppd is not the only problem:

$ grep -l "Required-Start.*network" *|xargs grep -l "Default-Start.*2"
bgpd
cntlm
collectl
drbd
ebtables
firebird
hp-drive-guard
mysql
o2cb
ocfs2
openhpid
ospf6d
ospfd
powerman
ripd
ripngd
rxstack
smpppd
sockd
wondershaper
zebra

So I see several ways to fix this:
1. fix all packages via maintenance update
2. undo the change in the network script
3. don't make insserv fail


CC maintenance, werner, coolo, mt for opinions

Hmmm ... in factory insserv is already changes to make it not fail
on such bugs. But this is (IMHO) not the correct solution.  The
scripts have to be fixed.

imo we should do an insserv update. It was never planned to make this fatal for 11.4 - just werner's "Freudian slip". For factory we need to fix this though - and I don't know a good way to catch them all beside rpmlint check

I've changed insserv:

  Wed Mar  9 09:38:37 CET 2011 - werner@suse.de
  - Correct Freudian slip

so we should do a maintenance update, and include the above fix. +1

Yes, starting update.

The SWAMPID for this issue is 39787.
This issue was rated as low.
Please submit fixed packages until 2011-04-27.
Also create a patchinfo file using this link:
https://swamp.suse.de/webswamp/wf/39787

already submitted:
 https://build.opensuse.org/request/show/64641

patchinfo file filled in

Hi folks,
I got a homework (#3)

djunix:/etc/init.d #  grep -l "Required-Start.*network"  *|xargs grep -l "Default-Start.*2"
mysql

but I have two questions (maybe dumb, but however :-))

Why the heck is insserv moaning about a runlevel problem that - as a matter of fact - does not exist (not a single reference to runlevel 4 in the entire directory /etc/init.d)?

Why does an _entirely empty_ INIT-INFO header of smpppd (let me guess: of any file within /etc/init.d ?) cause the very same error message?

After edit:
### BEGIN INIT INFO
# Provides:       smpppd
# Required-Start:
# Should-Start:
# Required-Stop:
# Should-Stop:
# Default-Start:
# Default-Stop:
# Description:    Start the smpppd for internet dial-up connections.
### END INIT INFO

djunix:/etc/init.d # insserv smpppd 
insserv: FATAL: service network is missed in the runlevels 4 to use service SuSEfirewall2_setup
insserv: exiting now!

Wouldn't it be possible to add a "-v" option to insserv that gives some real information? I've been trying to support you guys somehow, but the output of insserv -v <somefile> is not worth telling :-(

Thank you for clarifying ...

Take care







Dieter Jurzitza

Ok. Didn't leave me calm. Found one answer. SuSEfirewall was the culprit. 

But still: 
the error messages of insserv are ... say, difficult to interpret ...

Thanks


Dieter Jurzitza

(In reply to comment #10)
> already submitted:
>  https://build.opensuse.org/request/show/64641

This is aaa_base. I think we need an update of insserv here?

(In reply to comment #13)

insserv does walk down dependency chains, nothing more and nothing less.
If it run across a failure like cycles or missed dependcies it simply
gives a message.

It is a bug if e.g. SuSEfirewall2_setup is enabled by default in runlevel 4
and depends hard on network but the network service is missed in this runlevel.
And this is what the message

  insserv: FATAL: service network is missed in the runlevels 4 to use service
  SuSEfirewall2_setup

shows, isn't it?

For detection of cycles in dependency chains it is very difficult to
determine the cause of the loop if insserv reached a service a second time.
How to remeber the service which dependencies include a wrong turn.

Note that SuSEfirewall2_setup (and many other scripts) does not mention runlevel 4 anymore. Upgrade installations however may still have the symlinks in the now unused directory. "insserv -d script" should fix that.

(In reply to comment #14)

I can do nothing here this because I've just doen a branch
of openSUSE:11.4/insserv, checked out this, and now I've
seen that this version is identival to the already fixed
version for factory (beside the release number)

there still is this diff between insserv 11.4 and factory:
-+#ifndef OSCBUILD
++#ifdef OSCBUILD


Did you osc submitreq that change werner?`

Christian: Now what can be done?

(In reply to comment #18)

??

 werner/insserv> diff -u insserv-1.14.0.dif tmp/11.4/insserv-1.14.0.dif
 werner/insserv> 
 werner/insserv> grep OSCBUILD insserv-1.14.0.dif
 +#ifdef OSCBUILD
 +#ifdef OSCBUILD
 +#ifdef OSCBUILD
 +#ifdef OSCBUILD

... just tried to submit, see request 65688

the confusion resulted from the fact that coolo checked in 
a fixed insserv into :Update:Test bypassing all the other source repositories
we use fgor tracking.

Nothing more to do for you right now werner, I will clear this up.

btw, what bug is the aaa_base changed associated with, there are no bugreports listed in the changes entry?

These bugs I've seen at updating my old system at home compare
with bug #679277 ... I found some problems in aaa_base and
also in kbd during debugging the system in single user mode

In reply to #16:
You are totally right. Leftover symlinks in the unused directory (rc4.d ...) caused my problem. I could easily reproduce this.

Hard to detect for me. Question: if there are no active links to a directory (i. E. no scriptfile having relations to runlevel 4), wouln't it be possible to detect this? Couldn't one delete symlinks automatically, assuming that a link that isn't related to any dependency is invalid (I'am thinking of an array of unsigned int containing as many uints as runlevels, initialized to zero at the start of insserv. If a scriptfile in /etc/init.d refers to a runlevel by any means (Should Start, Should Stop, whatsoever), the corresponding entry in the array is increased by one.
At the end of the walk through /etc/init.d rnlvl[3] would still be zero now, that could provide the information that all links into rc4.d ought to be deleted as they are invalid)?

Just my 2 cents here, and, thanks a lot for helping me out - things work now (for me ...)

Take care




Dieter Jurzitza

(In reply to comment #24)
> In reply to #16:
> Hard to detect for me. Question: if there are no active links to a directory
> (i. E. no scriptfile having relations to runlevel 4), wouln't it be possible to
> detect this? Couldn't one delete symlinks automatically, assuming that a link
> that isn't related to any dependency is invalid

The admin could have placed the links in rc4 intentionally though.

I've fixed this bug and also submitted it.

Update released for: insserv, insserv-debuginfo, insserv-debugsource
Products:
openSUSE 11.4 (debug, i586, x86_64)

*** Bug 679407 has been marked as a duplicate of this bug. ***

*** Bug 680396 has been marked as a duplicate of this bug. ***