Comment 10 for bug 1037192

Hi Steve. I'm working with Niko on the server mountall problem. You're right that the 0.0.0.0 client address issue occurs because mountall is able to mount our NFS shares before it should. Initially upon startup, we run busybox's ipconfig (no tinc) and then rsync with the server to get system updates. After that, ifconfig is used to bring the device down and startup is to proceed as normal. It seems that some ip information must be hanging around, though. The log is recorded in mountall-0000.log

Adding an "ip addr flush" command prevents mountall from completing the mount before tinc is up. Unfortunately, it also keeps our shares from mounting at all. If while it's sitting there I issue a "mount /opt" command, then mountall seems to jump back in and continue with mounting /home. The log is mountall-flush.log and the lines at the end with "+" in front are after I've manually mounted /opt.

Adding "initctl emit -n net-device-up" to our tinc scripts prompts mountall-net.conf to send the SIGUSR1 signal. The logs show mount commands and the SIGUSR1 signal, but the network shares still don't come up unless I manually mount one. The log is mountall-net-device.log and the "+" lines are after the manual mount.

What I have gotten to work is a bit of a hack. Instead of depending on net-device-up, tinc sends out a custom signal (vpn-node-up), which mountall-net.conf is modified to listen for instead. I think the net-device-up signal is sent when the ethernet itself comes up, but before tinc is fully initialized. With the vpn-node-up signal, mountall-net only runs after tinc is up. The log for this is in mountall-hack.log. I would prefer to use the net-device-up signal properly if possible.

Please let me know what further information would be helpful.