# INIT scripts not starting in correct order

## nitro322

I'm having an issue with starting my network-based daemons.  Some of them are trying to start before net.eth0 and are failing.  Others, however, are beginning after net.eth0 as they should.  I can't find any reason for some to start properly and others to fail.  Here's a snippet from the boot log:

```
INIT: Entering runlevel: 3

 * Starting syslog-ng ...                                                                            [ ok ]

 * ERROR:  cannot start ntp-client as net.eth0 could not start

 * Starting portmap ...                                                                              [ ok ]

 * ERROR:  cannot start nfsmount as net.eth0 could not start

 * ERROR:  cannot start netmount as net.eth0 could not start

 * Setting up kdm ...                                                                                [ ok ]

 * Starting eth0

 *   Loading networking modules for eth0

 *     modules: apipa arping ccwgroup iptunnel macchanger macnet rename ifconfig ip6to4 system

 *       ifconfig provides interface

 *   Configuring eth0 for MAC address 00:2B:93:7C:DE:20 ...                                          [ ok ]

 *   Bringing up eth0

 *     192.168.0.4                                                                                   [ ok ]

 *   Adding routes

 *     default via 192.168.0.1 ...                                                                   [ ok ]

 * Starting sshd ...                                                                                 [ ok ]
```

So, ntp-client, nfsmount, and netmount are all trying to begin before net.eth0 is started and fail.  It seems that they recognize that net.eth0 needs to be started first, so I don't know why they're trying to start in this order.

The statement that "net.eth0 could not start" also puzzles me, as we can see just two lines below that net.eth0 starts just fine.  Also, as you can see at the very bottom, sshd starts properly once net.eth0 has started.

Any advice here?  I found a few mentions of this in the past through some searching, but I didn't have any luck finding a solution.

Thanks.

----------

## Telemin

Do you have RC_PARALLEL_STARTUP enabled in /etc/conf.d/rc?  If you do it may be trying to parallel start other services with net.eth0, so try disabling that.

Also try setting RC_NET_STRICT_CHECKING=yes, so that it expects all network interfaces to be up for net is considered up.  That way init will be made to wait until net.eth0 is started before trying to start any dependencies.

HTH

-Freestyling-

----------

## nitro322

Thanks for the suggestions, freestyling.  I tried setting RC_NET_STRICT_CHECKING=yes, and I've confirmed that RC_PARALLEL_STARTUP=no, but I still have the same issue.  Any other suggestions?

----------

## Telemin

I don't know what to suggest then.

You could try checking the "depend()" values in /etc/init.d/script for all the services that fail, and check that they have "need net" in them, but they should have, if not add the line and see.  You may need to post in bugzilla and get them permanently fixed.

The easy way according to the gentoo docs is to type "/etc/init.d/net.eth0 needsme" and check that the relevant services are listed or type "/etc/init.d/script ineed" and check that net is listed.

----------

## chrbecke

nitro322,

try running (as root) 

```
/sbin/depscan.sh -u
```

 and see if it fixes your problem.

This should update the dependency tree for your init scripts.

HTH,

Chris

----------

## nitro322

Thanks again for the replies.  Unfortunately, it still doesn't work.  chrbecke, I ran the command you suggested, and I didn't get any error messages, but it still begins in the wrong order.

freestyling, I had already manually checked the dependencies by viewing the init.d scripts and they seemed fine, but just to be certain I tried your suggestions as well.  'net.eth0 needsme' lists all of the scripts that it should, including the ones that are trying to start before it's loaded.  'netmount ineed' (as well as the other two) properly lists net as a dependency.  It doesn't specifically mention net.eth0, but I don't think it's supposed to, correct?

Any other suggestions?  or have I perhaps found a bug that needs to be fixed?

Thanks for your help.

----------

## UberLord

 *nitro322 wrote:*   

> Any other suggestions?  or have I perhaps found a bug that needs to be fixed?

 

Have you got the file /etc/init.d/net or have NetworkManager installed?

You can always try baselayout-2 (p.masked and has known bugs) to see if the service ordering issue has been fixed.

----------

## Telemin

Actually, having just looked at Uberlords Sig, have you run etc-update or dispatch-conf recently??

If you haven't it may be that some new init scripts revisions are ready to be added and they will solve the problem.

----------

## nitro322

UberLord - I'm using /etc/init.d/net.eth0 with a manually configured /etc/conf.d/net.  I can provide the net configuration if you'd like, but I don't see anything in there that should be relevant to service start order.  I haven't heard of NetworkManager, so I'm guessing I don't have that installed.

As for baselayout-2...  I'd rather leave that to the professional bug wranglers.   :Smile:   I generally prefer to stick with stable releases where possibly, simply because I usually have enough issues to deal with even without unstable/beta releases.

freestyling - Yes, I have run etc-update recently.  There are no ._cfg* files available to update.  Good suggestion, though.

----------

## Simius

It seems this isn't your problem, but still I'll post it here, as I have found a new source of init script disorders, and its solution too.

If you are using the new xinit, there is a new "feature" implemented to speed up system startup by starting xdm as soon as possible. Well, that would be all well if it didn't break kdm and gdm in many cases.

Here is what you need to do: In /etc/conf.d/xdm you need to set 

```
XSTATICVT="no"
```

With this setting, no modification to /etc/init.d/xdm is needed.

I was surprised at first, and thought that this is part of the stable baselayout. Well, in actuality, it was in the ~arch xinit. Still, at least this should have been "no" by default...

----------

## UberLord

 *nitro322 wrote:*   

> UberLord - I'm using /etc/init.d/net.eth0 with a manually configured /etc/conf.d/net.  I can provide the net configuration if you'd like, but I don't see anything in there that should be relevant to service start order.  I haven't heard of NetworkManager, so I'm guessing I don't have that installed.

 

Well, we have a lot of people testing baselayout (all our users  :Smile:  ) and no-one has reported that bug so far, so I would suggest it is a configuration issue somehow.

Download this file

http://dev.gentoo.org/~uberlord/baselayout/trace-test

put it in /etc/init.d and chmod +x it

Then run it and it will show the ordering of services. Please post that here, along with /etc/conf.d/rc

 *Quote:*   

> As for baselayout-2...  I'd rather leave that to the professional bug wranglers.    I generally prefer to stick with stable releases where possibly, simply because I usually have enough issues to deal with even without unstable/beta releases.

 

Fair enough.

----------

## nitro322

 *UberLord wrote:*   

> Then run it and it will show the ordering of services. Please post that here, along with /etc/conf.d/rc

 

```
blackdog init.d # ./trace-test start

 * Caching service dependencies ...                                       [ ok ]

Boot services:

checkroot modules checkfs localmount clock hostname bootmisc keymaps consolefont net syslog-ng net.eth0 ntp-client portmap nfsmount netmount xdm net.lo rmnologin urandom

default services

checkroot modules checkfs localmount clock hostname bootmisc keymaps consolefont net syslog-ng ntp-client portmap nfsmount netmount xdm net.lo net.eth0 numlock rmnologin sshd urandom vixie-cron local

Shutdown services

local vixie-cron urandom sshd rmnologin numlock alsasound xdm netmount nfsmount portmap ntp-client net.eth0 net.lo syslog-ng net consolefont keymaps bootmisc hostname clock localmount checkfs modules checkroot
```

```
blackdog init.d # cat /etc/conf.d/rc

RC_TTY_NUMBER=11

RC_PARALLEL_STARTUP="no"

RC_INTERACTIVE="yes"

RC_HOTPLUG="yes"

RC_COLDPLUG="yes"

RC_PLUG_SERVICES=""

RC_NET_STRICT_CHECKING="yes"

RC_DOWN_INTERFACE="yes"

RC_VOLUME_ORDER="raid evms lvm dm"

RC_VERBOSE="yes"

RC_BOOTLOG="yes"

RC_BOOTCHART="no"

RC_USE_FSTAB="no"

RC_USE_CONFIG_PROFILE="yes"

RC_FORCE_AUTO="no"

RC_DEVICES="auto"

RC_DEVICE_TARBALL="no"

RC_SWAP_ERASE="no"

RC_DMESG_LEVEL="1"

RC_RETRY_KILL="yes"

RC_RETRY_TIMEOUT=1

RC_RETRY_COUNT=5

RC_FAIL_ON_ZOMBIE="no"

RC_KILL_CHILDREN="no"

RC_WAIT_ON_START="0.1"

svcdir="/var/lib/init.d"

svcmount="no"

svcfstype="tmpfs"

svcsize=2048
```

Also, just in case:

```
blackdog init.d # cat /etc/conf.d/net

config_eth0=( "192.168.0.4 netmask 255.255.255.0 broadcast 192.168.0.255" )

routes_eth0=( "default via 192.168.0.1" )

dns_servers_eth0="192.168.0.2"

ntp_servers_eth0="192.168.0.2"

dns_domain_eth0="legroomm.net"

dns_search_eth0="legroom.net"

dns_domain_lo="legroom.net"
```

Thanks again for helping me look into this.

----------

## UberLord

Is net.eth0 in the default, boot or none runlevels? Is it coldplugged?

Try adding it to the boot runlevel.

----------

## nitro322

It's in the default runlevel, only default.  I'll try adding it to boot and see what happens.

No, it's not coldplugged.  I don't even have that package installed.

----------

## nitro322

Well, that worked.  It seems like more of a workaround than a proper solution, but I'll take what I can get right now.   :Smile:   Still, net.eth0 doesn't strike me as something that should go in boot.  Should I still file a bug report about this anyway, so it can be looked at and cleaned in a future update, or just leave it as it is?

----------

## UberLord

Up to you. As you're the only person that has this issue with a stable package that I know of the chances are it will be hard to fix corner case.

In other words we probably won't look into it that much as we're concentrating on baselayout-2 right now.

----------

## l8bit

 *nitro322 wrote:*   

> Well, that worked.  It seems like more of a workaround than a proper solution, but I'll take what I can get right now.    Still, net.eth0 doesn't strike me as something that should go in boot.  Should I still file a bug report about this anyway, so it can be looked at and cleaned in a future update, or just leave it as it is?

 

I had similar problems with net.lo (https://forums.gentoo.org/viewtopic-t-553982-highlight-.html) after adding it to the default level as it didn't strike me to add it to the boot level either. After I did tho everything was solved and scripts were running in correct order (even with parallel start-up).

----------

## techsyn

I don't think this is an isolated problem.

Could this problem be caused by the new gentoo-sources  version 2.6.20-r6  :Question: 

Just wondering.

techsyn

----------

## TheWolf

I don't think it is an isolated problem either since I'm experiencing the same. But it surely has nothing to do with the new kernel as I am still running 2.6.18-r6. I'm pretty sure it came with the update to baselayout-1.12.9-r2, before that I never had this problem.

----------

## UberLord

In that case someone should really file a bug  :Smile: 

----------

## Ralphus Maximus

I hate to sound AOL'ish, but me too on a new install. Moving the net.eth0 to the boot runlevel did the trick.

I've not updated my other boxen in some time, so I don't know if the problem will follow or not. I may get brave this weekend and try it.

Or not.    :Very Happy: 

Cheers,

RM

----------

## gsoe

This seems to be a hard one to solve, but I think that Simius touches something of concern. 

I'm using kdm and I had the same problem some time ago, in my case netmount would try to start before net.eth0. The interesting thing is, that if I removed xdm from the default runlevel, everything behaved fine. I never found out what was wrong, and as I didn't need netmount, I just left it out. Funny thing is that I installed two machines with only one day in between, one showed the problem, the other didn't, and I just couldn't find any notable difference to explain it.

Now the problem machine does not exhibit the problem anymore, and of course I didn't notice when this change happened as I haven't been using netmount.

cheers

----------

