From: Timo Juhani Lindfors on
Camale�n <noelamac(a)gmail.com> writes:
> So we are doing something wrong here.

It seems that /etc/init.d/mountnfs.sh does not actually call mount, it
is done by

/etc/network/if-up.d/mountnfs

when a network interface is brought up.

Should I try starting bind9 before network is brought up? That sounds
very counter-intuitive.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/8439us6idg.fsf(a)sauna.l.org
From: Timo Juhani Lindfors on
Timo Juhani Lindfors <timo.lindfors(a)iki.fi> writes:
> Should I try starting bind9 before network is brought up? That sounds
> very counter-intuitive.

Replying to myself here: this fails since bind9 says "no networks
configured". A hack that works for now seems to be to add

if [ "$(pidof named)" = "" ]; then
/etc/init.d/bind9 start
fi

to /etc/network/if-up.d/bind9. If we assume that "lo" is the first
interface that is brought up then bind9 gets started after lo has been
brought up but before "br0" has been brought up. This then guarantees
that when "br0" is brought up /etc/network/if-up.d/mountnfs has
working DNS.

A better solution would be appreciated.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/84y6cj6gsl.fsf(a)sauna.l.org
From: Camaleón on
On Fri, 06 Aug 2010 15:22:19 +0300, Timo Juhani Lindfors wrote:

> Camaleón writes:
>> So we are doing something wrong here.
>
> It seems that /etc/init.d/mountnfs.sh does not actually call mount, it
> is done by
>
> /etc/network/if-up.d/mountnfs
>
> when a network interface is brought up.
>
> Should I try starting bind9 before network is brought up? That sounds
> very counter-intuitive.

That does not make sense to me either :-/

A quick question: your log marks NFS service as "done", does it really
works despite the warning or the share is not getting mounted once the
system boots?

Another question that rounds my head... does the resolution fails because
of bind9 not being available or is it failing due to the network is not
still ready? :-?

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/pan.2010.08.06.13.25.54(a)gmail.com
From: Sven Joachim on
On 2010-08-06 10:01 +0200, Timo Juhani Lindfors wrote:

> With
>
> nfs:/home /home nfs defaults 0 0
>
> in /etc/fstab I get
>
> mount.nfs: Failed to resolve server nfs: Temporary failure in name resolution
>
> on boot. This is because I use local bind9 and /etc/resolv.conf has
>
> nameserver 127.0.0.1

And bind9 is started after mountnfs, that's for sure.

> I tried adding " bind9" to the $remote_fs line of /etc/insserv.conf but got
>
> $ sudo insserv --dryrun
> insserv: There is a loop between service bind9 and rsyslog if started
> insserv: loop involving service rsyslog at depth 8
> insserv: loop involving service bind9 at depth 7
> insserv: loop involving service mountnfs at depth 5
> insserv: loop involving service atd at depth 11
> insserv: exiting now without changing boot order!

Yes, bind9 depends itself on $remote_fs so there is a loop.

> Any idea on how to proceed? I'd hate to use numeric IP addresses.

Changing both bind9's and rsyslog's dependency to $local_fs (either in
the init scripts themselves or in override scripts in
/etc/insserv/overrides) and starting rsyslog and bind9 in runlevel S
might work.

This sucks, but it is mainly because Debian's boot system starts the
network in runlevel S already which is IMO wrong but hard to correct.

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/87d3tvdfhb.fsf(a)turtle.gmx.de