Understanding the startup sequence

[pwabrahams]

I need to take a certain action during startup after all the normal startup actions have completed (filesystems mounted, network started up, etc.). I know that etc/init.d/rc.local is executed during startup, but I don't know at what point in the sequence. Is there a description of just what is done during startup?

A bit of context: I have a problem with a certain cifs mount not getting done during startup because the device is not yet connected. It appears that it needs to be tried repeatedly until it works. I've tried various additions to the fstab entry, but none of them so far have worked. So I'd like to try a different approach, using the following script or something like it:

until grep /proc/mounts mediavault; do
mount /media/mediavault
sleep 2
done

The idea is to retry the mount every 2 seconds until it succeeds.

[sithlord48]

Re: Understanding the startup sequence

try this...

manually set your /etc/network/interfaces file , creating one will disable network manger, so be warned. but it will how ever start up much eariler. (this is how i mount my nfs on boot).

[code= /etc/network/interfaces example]

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

#auto eth0
#iface eth0 inet static
#address 192.168.0.101
#netmask 255.255.255.0
#gateway 192.168.0.1
#dns-nameservers 24.148.96.1 24.148.96.2

[/code]
the '#' is a commented line, the first eth0 section is for dhcp , the second for manual ip config, if you use manual you may also have to create a /etc/resolv.conf file as well

[code= /etc/resolv.conf]
nameserver <dnsIP>
[/code]

to un do this you need to only remove the /etc/network/interfaces and /etc/reslov.conf files.

[pwabrahams]

Changing /etc/network/interfaces

The trouble I'm having seems to be that the connection takes a long time to become established, so starting the process earlier doesn't solve the problem. I specifically need some method of retrying the mount until it works, no matter how long that takes. Actually, the code I proposed should be enclosed in ( ...)& so that it runs in parallel with everything else and eventually goes away when it completes.

The filesystem I'm mounting is a Windows-type share, mounted via smbmount. That type of mount has fewer options than an nfs mount; in particular, it lacks the bg option that in theory should solve the problem. But in fact I've encountered this difficulty also with nfs mounts where bg was among the options.

[vinnywright]

Re: Understanding the startup sequence

dont know if it will help you but found this

http://www.linux-noob.com/forums/ind...with-smbmount/

about halfway down is the relavent part!

talking about a Karmic bug and a fix.

VINNY

[kubicle]

Re: Understanding the startup sequence

I know that etc/init.d/rc.local is executed during startup, but I don't know at what point in the sequence.

To answer this one, /etc/rc.local is run last at the end of init/upstart boot process (the init symlink that calls it is /etc/rc2.d/S99rc.local-->/etc/init.d/rc.local-->/etc/rc.local).

[pwabrahams]

Specific solution but general question not yet answered

The code I gave earlier, when placed in rc.local, does work, except that I reversed the arguments to grep. Last time I dealt with this, an explicit mount in rc.local didn't work because the CIFS device was still not yet available. This code says "keep trying until it is available no matter how long that takes, then exit".

The general question is where I can find a good explanation of the startup sequence, starting with the kernel's invocation of init. I've figured out most of it, but I don't yet see just how rc.local gets invoked.

[kubicle]

Re: Specific solution but general question not yet answered

The general question is where I can find a good explanation of the startup sequence, starting with the kernel's invocation of init.

You can start with 'man -a init' and read other man pages as suggested in the man pages

I've figured out most of it, but I don't yet see just how rc.local gets invoked.

*buntus use upstart, which is an event-based init daemon. kernel starts init and init performs jobs defined in /etc/init/.

To make it a bit complicated, for compatibility with LSB and the old SysVInit system, upstart also has a job for running the old style init-scripts (these can be found in /etc/init.d/).

Which init.d scripts are actually run is defined by symlinks in /etc/rcX.d (where X is the runlevel, 2 is the default), which are run in numerical order (S means start and K means stop).

So, by default, upstart runs the the /etc/init.d scripts that have SXXscript symlinks in /etc/rc2.d/...and as there is /etc/rc2.d/S99rc.local symlink, the script /etc/init.d/rc.local is executed at the end of the boot process.

And what /etc/init.d/rc.local does, is basically run the commands in /etc/rc.local.

[pwabrahams]

Re: Specific solution but general question not yet answered

To make it a bit complicated, for compatibility with LSB and the old SysVInit system, upstart also has a job for running the old style init-scripts (these can be found in /etc/init.d/).

That's what confused me.

[vinnywright]

Re: Understanding the startup sequence

I may be rong but but I think I remember somthing else like this from a different post and it had to do with a NFS mount ....but same prob mabey..

it's that the KDE network manegment dosent start untill after login so thars no share to mount untill after your loged in.

I think the poster thare worked it out with gnome netwok manegment that started during boot!!

just a thought sorey if I'm way off bace.

VINNY

[pwabrahams]

Delayed connections

I've determined that the code I gave earlier is really necessary. I augmented it with a count of mount attempts and it showed 11 attempts before success -- a delay of 24 seconds.