* [gentoo-user] Network start delay?
@ 2007-02-07 10:37 Peter Lewis
2007-02-07 23:12 ` Iain Buchanan
0 siblings, 1 reply; 4+ messages in thread
From: Peter Lewis @ 2007-02-07 10:37 UTC (permalink / raw
To: gentoo-user
Hi all,
I have a quick question about my init scripts.
I start my wireless network with the script
/etc/init.d/net.eth2
which is started by init in the "default" runlevel.
I also have
/etc/init.d/netmount
to mount some samba shares, and which is also started my init in the "default"
runlevel, but depends on "net" from the line:
local myneed="net"
So, as I understand it, this makes sure that init starts net.eth* before
starting netmount. That's good. However, eth2 is on a DHCP-enabled connection
and takes a few seconds to come up after starting the script. By the time
netmount is started, net.eth2 has not finished coming up, so netmount fails
and the samba shares are never mounted automatically.
Is there a way to make the netmount script wait for a route to exist before
attempting to connect?
Thanks!
Pete.
--
gentoo-user@gentoo.org mailing list
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-user] Network start delay?
2007-02-07 10:37 [gentoo-user] Network start delay? Peter Lewis
@ 2007-02-07 23:12 ` Iain Buchanan
2007-02-08 13:23 ` Peter Lewis
0 siblings, 1 reply; 4+ messages in thread
From: Iain Buchanan @ 2007-02-07 23:12 UTC (permalink / raw
To: gentoo-user
On Wed, 2007-02-07 at 10:37 +0000, Peter Lewis wrote:
> Hi all,
>
> I have a quick question about my init scripts.
>
> I start my wireless network with the script
>
> /etc/init.d/net.eth2
>
> which is started by init in the "default" runlevel.
>
> I also have
>
> /etc/init.d/netmount
>
> to mount some samba shares, and which is also started my init in the "default"
> runlevel, but depends on "net" from the line:
>
> local myneed="net"
>
> So, as I understand it, this makes sure that init starts net.eth* before
> starting netmount. That's good. However, eth2 is on a DHCP-enabled connection
> and takes a few seconds to come up after starting the script. By the time
> netmount is started, net.eth2 has not finished coming up, so netmount fails
> and the samba shares are never mounted automatically.
>
> Is there a way to make the netmount script wait for a route to exist before
> attempting to connect?
net.eth2 "shouldn't" return (by default) until it has a dhcp address,
which means all other scripts starting after it will wait until you have
an address.
Things you might have done to change the default behaviour include
RC_PARALLEL_STARTUP, and RC_NET_STRICT_CHECKING in /etc/conf.d/rc.
You can set them to "no", and "yes" respectively and see if the
following scripts wait...
HTH,
--
Iain Buchanan <iaindb at netspace dot net dot au>
When you're in command, command.
-- Admiral Nimitz
--
gentoo-user@gentoo.org mailing list
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-user] Network start delay?
2007-02-07 23:12 ` Iain Buchanan
@ 2007-02-08 13:23 ` Peter Lewis
2007-02-08 23:12 ` Iain Buchanan
0 siblings, 1 reply; 4+ messages in thread
From: Peter Lewis @ 2007-02-08 13:23 UTC (permalink / raw
To: gentoo-user
On Wednesday 07 February 2007 23:12, Iain Buchanan wrote:
> On Wed, 2007-02-07 at 10:37 +0000, Peter Lewis wrote:
> > I start my wireless network with the script
> >
> > /etc/init.d/net.eth2
> >
> > which is started by init in the "default" runlevel.
> >
> > I also have
> >
> > /etc/init.d/netmount
> >
> > to mount some samba shares, and which is also started my init in the
> > "default" runlevel, but depends on "net" from the line:
> >
> > local myneed="net"
> >
> > So, as I understand it, this makes sure that init starts net.eth* before
> > starting netmount. That's good. However, eth2 is on a DHCP-enabled
> > connection and takes a few seconds to come up after starting the script.
> > By the time netmount is started, net.eth2 has not finished coming up, so
> > netmount fails and the samba shares are never mounted automatically.
> >
> > Is there a way to make the netmount script wait for a route to exist
> > before attempting to connect?
>
> net.eth2 "shouldn't" return (by default) until it has a dhcp address,
> which means all other scripts starting after it will wait until you have
> an address.
>
> Things you might have done to change the default behaviour include
> RC_PARALLEL_STARTUP, and RC_NET_STRICT_CHECKING in /etc/conf.d/rc.
>
> You can set them to "no", and "yes" respectively and see if the
> following scripts wait...
Thanks for this. I just checked and I have those variables set up correctly.
Yes, upon closer inspection, the problem is slightly weirder.
I'm using an Intel ipw3945 wireless device, which requires a daemon to run
to "regulate it" or something. So, I also have /etc/init.d/ipw3945d start at
boot. This must start before I can access eth2. However, I've actually just
noticed that I don't explicitly start net.eth2 in any runlevel. It seems that
this is kicked into action by ipw3945d somewhere (though I can't see where).
The /etc/init.d/net.eth2 process just seems to fork off to the background,
meaning that init carries on booting, and hence fails on netmount.
Anyone any experience with this?
Cheers,
Pete.
--
gentoo-user@gentoo.org mailing list
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-user] Network start delay?
2007-02-08 13:23 ` Peter Lewis
@ 2007-02-08 23:12 ` Iain Buchanan
0 siblings, 0 replies; 4+ messages in thread
From: Iain Buchanan @ 2007-02-08 23:12 UTC (permalink / raw
To: gentoo-user
On Thu, 2007-02-08 at 13:23 +0000, Peter Lewis wrote:
> On Wednesday 07 February 2007 23:12, Iain Buchanan wrote:
> > On Wed, 2007-02-07 at 10:37 +0000, Peter Lewis wrote:
[snip]
> > > Is there a way to make the netmount script wait for a route to exist
> > > before attempting to connect?
> >
> > net.eth2 "shouldn't" return (by default) until it has a dhcp address,
> > which means all other scripts starting after it will wait until you have
> > an address.
> >
> > Things you might have done to change the default behaviour include
> > RC_PARALLEL_STARTUP, and RC_NET_STRICT_CHECKING in /etc/conf.d/rc.
> >
> > You can set them to "no", and "yes" respectively and see if the
> > following scripts wait...
>
> Thanks for this. I just checked and I have those variables set up correctly.
>
> Yes, upon closer inspection, the problem is slightly weirder.
>
> I'm using an Intel ipw3945 wireless device, which requires a daemon to run
> to "regulate it" or something. So, I also have /etc/init.d/ipw3945d start at
> boot. This must start before I can access eth2. However, I've actually just
> noticed that I don't explicitly start net.eth2 in any runlevel. It seems that
> this is kicked into action by ipw3945d somewhere (though I can't see where).
> The /etc/init.d/net.eth2 process just seems to fork off to the background,
> meaning that init carries on booting, and hence fails on netmount.
>
> Anyone any experience with this?
yeah, I have services starting without me asking for them too :) It
seems to happen when the module is loaded. Supposedly, you control this
behaviour with
RC_PLUG_SERVICES=... Have a read in /etc/conf.d/rc again for more info
on this. It doesn't work for me however, I have it set to "!bluetooth",
and yet /etc/init.d/bluetooth is _always_ started.
What happens if you set RC_PLUG_SERVICES="!net.eth2", and then
explicitly add net.eth2 to your runlevel? maybe you need to put a dep in
it so it starts after ipw3945d?
HTH,
--
Iain Buchanan <iaindb at netspace dot net dot au>
And then there was the lawyer that stepped in cow manure and thought
he was melting...
--
gentoo-user@gentoo.org mailing list
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-02-08 23:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-02-07 10:37 [gentoo-user] Network start delay? Peter Lewis
2007-02-07 23:12 ` Iain Buchanan
2007-02-08 13:23 ` Peter Lewis
2007-02-08 23:12 ` Iain Buchanan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox