You are not logged in.
Can i delay the mounting of my network drives (cifs) at the boot up?
I want to do this to be able to start network in the background at the boot up since thats the procedure slowing down the boot up at the moment.
Thank you in advance.
Last edited by djungelmums (2011-02-08 21:31:50)
Offline
make sure your netfs/cifs is listed after network in your DAEMONS array
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Using a static ip address instead of dhcp will speed things up too since the comp won't have to negotiate with the router for an address. I just moved and used dhcp for the first time in ages and really noticed how it slowed boot times. I went straight back to static addresses then.
You're just jealous because the voices only talk to me.
Offline
Or do something similar to this:
in /etc/rc.local:
(sleep 10; /root/bin/MountDlink-323)&
where MountDlink-323 is a script that mounts my network file server.
Mektub
Follow me on twitter: https://twitter.com/johnbina
Offline
Look into AutoFS; you might like it. I find it very useful for automatically mounting my cifs shares only when I access them, and then automatically unmounting them after 60 seconds of inactivity. If you use AutoFS, you won't need to have your cifs shares as static mounts in the fstab.
Last edited by flan_suse (2011-02-09 04:52:24)
Offline
Thank you for your answers.
Inxsible: Netfs is already after network in my daemons array. Does it have to be backgrounded too if i background network?
Offline
Thank you for your answers.
Inxsible: Netfs is already after network in my daemons array. Does it have to be backgrounded too if i background network?
yes absolutely. if you background network you definitely need to background netfs, because netfs requires network to be up and running for obvious reasons.
All non-backgrounded daemons in the array will be started before the backgrounded ones or before you can go further.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
djungelmums wrote:Thank you for your answers.
Inxsible: Netfs is already after network in my daemons array. Does it have to be backgrounded too if i background network?
yes absolutely. if you background network you definitely need to background netfs, because netfs requires network to be up and running for obvious reasons.
All non-backgrounded daemons in the array will be started before the backgrounded ones or before you can go further.
No. The script (rc.multi ; rc.d/functions) processes the correct order. It depends on the runtime of the specific daemon-script.
Last edited by metzengerstein (2011-02-09 16:50:36)
Offline
But wouldn't you need the network to be up and running before you are able to access/mount network drives???
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Sure. You just mentioned that the @-marked daemons are processed after the unmarked. But there is no queueing or sorting, they are just send to background.
So for example "DAEOMONS=(@network ... other daemons ... netfs)" should work, if @network doesn't run too long.
Last edited by metzengerstein (2011-02-09 17:39:55)
Offline
Ahh ! I wasn't sure which statement you were refuting.
but this confuses me a little. We normally background DAEMONS to increase boot speed (or atleast one of the reasons). So I assume that when you background it, you run it parallely along with moving ahead in your startup process -- namely starting up other daemons and bringing up the login screen/Display Manager or booting straight to X.
OTOH, unmarked daemons actually get started before going ahead in the start up process. So wouldn't that mean that they might get started before anything else is processed...?
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Ahh ! I wasn't sure which statement you were refuting.
but this confuses me a little. We normally background DAEMONS to increase boot speed (or atleast one of the reasons). So I assume that when you background it, you run it parallely along with moving ahead in your startup process -- namely starting up other daemons and bringing up the login screen/Display Manager or booting straight to X.
Correct
OTOH, unmarked daemons actually get started before going ahead in the start up process. So wouldn't that mean that they might get started before anything else is processed...?
Why?
Here is the code:
# Start daemons
for daemon in "${DAEMONS[@]}"; do
if [ "$daemon" = "${daemon#!}" ]; then
if [ "$daemon" = "${daemon#@}" ]; then
start_daemon $daemon
else
start_daemon_bkgd ${daemon:1}
fi
fi
done
if [ -x /etc/rc.local ]; then
/etc/rc.local
fi
Translated into human language:
For every daemon in the DAEMON array do:
If daemon has not the prefix "!" do:
if daemon has not the prefix "@" do: start the daemon --> AND wait for comletion
else do: start the daemon in background --> AND don't wait for completion
Process rc.local
...
Hope thats clear now
Offline
yes... i was under the assumption that all the non-backgrounded ones get processed (or started) before the other daemons. So I stand corrected.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
I also had a problem with netfs because it took too long for my network to get up in my laptop and when netfs was started, my network drives wasn't mounted. Maybe because I use wicd in archbang. My workaround was to make a script for starting netfs delayed.
/etc/rc.d/delayed-netfs (you need to change IP ofcourse)
#!/bin/bash
until ping 123.456.789.123 -c1 &> /dev/null; do
sleep 3
done
/etc/rc.d/netfs start
Then I added @delayed-netfs in my /etc/rc.conf daemons. Script will be ran in the background and will start the netfs daemon when NAS is available.
I used my NAS IP directly in the script but there are probably smarter ways . This has worked well for me. For example now that I'm not at home it will not unnecessarily start netfs.
Offline
@steeni
Even if your solution works, when dealing with daemons you should consider the guidline at https://wiki.archlinux.org/index.php/Wr … .d_scripts
Or alternativly you could append the code in your rc.local.
Offline