Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I have noticed that when I unplug the network cable, system waits about 100 seconds to configure the network, So I edited /etc/init/failsafe.conf and comment two wait() lines (thanks to tutorial here)

# Plymouth errors should not stop the script because we *must* reach
# the end of this script to avoid letting the system spin forever
# waiting on it to start.
    $PLYMOUTH message --text="Waiting for network configuration..." || :
    #sleep 40

    $PLYMOUTH message --text="Waiting up to 60 more seconds for network configuration..." || :
    #sleep 59
    $PLYMOUTH message --text="Booting system without full network configuration..." || :

Then I grab a timer and start counting seconds of boot time, the odd thing is it takes 15 more seconds to boot a system with an unplugged network cable that a system with a plugged network cable. and most of the delay is in this line that appears on start up :

the disk driver for servername--vg-swap1 not ready

My home folder is encrypted and Ubuntu has been installed with LVM.

Maybe you say "so what harm can come from 15 more seconds of delay?" Well, I am configuring this server to be used in a traffic control system and in case of power failure the system should be back on its feet as soon as possible, so every second counts.

Thank you.

share|improve this question
    
My question is completely unrelated. The targeted use of the system sounds like a serious gig. Why do you use ubuntu for that? For your use it is probably full of unnecessary packages... The delay in starting is that if you have address managed by DHCP, the system waits very long time for the DHCP response. Using static addresses would solve your problem. Or, there is a crappy solution I just made up - start the machine without network and create a script to manually configure network connection at the time the system is running. –  Fiisch May 14 '13 at 21:07
    
thnx for comment, for your first question, the customer wants to use this computer not only as a server but also as a operator computer to work with application (web app in this case) so the OS should have some ui and user friendly aspects also. i know this is wrong but cant argue with customer –  dave May 15 '13 at 11:17
2  
well if this is a webapp, you can access it from somewhere else, that is not a reason to have direct access to the server. tip: tell the customer it is a basic security measure - what if somebody accidentally turns the machine off like it was an ordinary desktop? what if somebody plugs there infected usb stick? you can name all basic problem that ordinary pebkac can cause. do the customer really want this happen? because sooner or later it will happen. i don't say to argue with customer, but if you feel this is wrong, do not worry to tell them, give advice AND (important!) a solution. –  Fiisch May 15 '13 at 15:47
    
I agree with @Fisch. For your project you must consider a mission critical solution. It must be both secure and always available. For a system like this I would go so far as to propose a redundant system to handle fail-over to a secondary server (possibly using heartbeat) and even then the 10 to 15 sec time to switch would be critical. It takes less than that for a traffic accident to happen. And if your client gives you any crap about "budget constraints" ask them what price tag they put on a lost limb or a human life for that matter. –  hmayag May 15 '13 at 22:25
    
Just have to chime in here as well. Oh it's a server and Oh it's a workstation is a HORRID AND TERRIBLE (I can't make that caps enough) idea. Install Ubuntu server on Linode or AWS and sell the customer on buying a workstation. If your customer still persists that they want to use it as a workstation too, then they're wrong (it happens). More importantly Your wrong, and doing a poor job because your not solving their primary/root problem. Servers and workstations are different and network access is just one of the many ways. Find and solve their real problem. Both you and they will be happier. –  coteyr May 17 '13 at 15:00

2 Answers 2

up vote 1 down vote accepted
+50

Do you have eth0 set up to be automatic by DHCP? Look at /etc/network/interfaces (it's a file, not a folder)

If your entry looks something like this:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

then that large delay is because your system is trying to run DHCP, even though the network cable is unplugged, which means it runs through all of the channels until it gets a response, which it never will because it's not plugged in, so it takes a while. If it's plugged in, this is much faster because it should get a DHCP offer fairly quickly.

That would be the best explanation I can think of.

share|improve this answer
    
thnx for reply - let me check that and come back to you –  dave May 15 '13 at 11:20

If you insist on speeding up your boot time, you should boot with nothing running. After the system is up and running then enable devices and system applications.

Set the machine to boot to console only with no networking, then in rc.local set a script to sleep a while then enable networking and other services. You should be able to "boot" in under 5 seconds (after grub hands off) on good hardware.

However, based on your comments, this is not the best answer. If "server" portion would be 100% useless without a network, and your "workstation" portion would be 100% useless without a network (you said web app). So your fast booting Linux box would still be 100% useless for longer then if you booted normally. Also if you using "normal" server hardware you probably spend much more time on pre-bootloader setup and posting then you do in Linux boot.

Also if your server is running critical software you should cluster with two or more and a long boot time should matter.

In short, changing the boot order in this way, while booting faster, will almost certainly take longer to recover from a outage.

If your trying to speed up network access then disabling DHCP and using a static IP should help. Also consider that even with "the plug in" spanning tree algorithms on the switch may take a while before you get real network access.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.