Bug#806949: ifupdown: some tweaks to networking.service

[Bob Proulx]

Michael Biebl wrote:
> schrieb Bob Proulx:
> > If a client system requires an NFS mounted file system then the admin
> > must configure the network to be "auto" and not "allow-hotplug".
> > The simple reason is that because otherwise it won't work. :-)
> 
> That's not quite acurate. The if-up.d hook scripts did work for
> allow-hotplug under sysvinit. It just meant, the NFS share was mounted
> at an arbitrary point during boot.
> So allow-hotplug and SysV init scripts with Required-Start: $network was
> not a good combination.

I am talking about the traditional sysvinit system here.  It needs
"auto" for it to work properly for NFS mounted file systems.

For example a small corporate workstation which requires a hard
mounted NFS mounted (no autofs) $HOME for a user to be able to log
into the system.  For that to happen then the network must be online
before the NFS mounts are attempted and before the user has a login
prompt available.  Environments such as that tend to use other hard
mounted NFS file systems other than $HOME too.  The easiest way to
ensure this is with "auto" for the network.  Although I am sure it is
possible to tinker something together in the event driven path through
"allow-hotplug" but that has never worked by default for me.  There
hasn't ever been an itch to scratch to make allow-hotplug to work in
that type of environment since there it doesn't make sense to have
$HOME on a sometimes-there sometimes-not-there interface.

> Under systemd mounting works a bit differently and fails hard if network
> is not yet up when the remote mounts are triggered.

I am not running systemd and my comments were concerning Jessie,
Wheezy and previous releases using sysvinit.  Jessie with sysvinit
seems the same to me as the previous releases in this behavior.

> So this is a regression compared to wheezy.

There are many facets and one must be careful to be specific about the
specific part of it.  As far as needing auto versus allow-hotplug I
don't see any regression on that particular facet of the issue.

Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20151223/50b5fff9/attachment-0002.sig>