FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Development

 
 
LinkBack Thread Tools
 
Old 03-16-2009, 01:14 PM
Thierry Carrez
 
Default Shutdown sequence and Network filesystems

Hello everyone,

We have various long-standing issues in the shutdown/reboot sequence of
events, when network filesystems are involved. Several bugs have been
filed (bug 113095, bug 211631) but they point to the same issue. Since
it affects several packages, I would like to discuss the possible
solutions here.

To cut those long threads short, the problem is that on
NetworkManager-enabled systems, we kill networking at S20sendsigs,
before S31umountnfs.sh. This leads to various timeout errors in
umountnfs.sh and potentially to data loss on the network filesystems.

There are three ways of handling your network:

1- Without using NetworkManager
Then everything works fine

2- With Networkmanager with connection in "Available for all users" mode
S20sendsigs kills NetworkManager, dhclient and wpasupplicant, resulting
in loss of network connection. S31umountnfs.sh fails with various
timeouts/errors.

3- With NetworkManager with connection in default mode (per-user)
When Gnome session is terminated, the network connection is killed... by
design. So umountnfs.sh fails as well.

Should we support option (3), mounting network filesystems on a network
connection in per-user mode ? It seems bound to failure by design. At
that point I would say it probably makes sense to fix it for option (2)...

How could we do this ? From my analysis it appears we need to protect
from the evil S20sendsigs the following processes:
- NetworkManager
- nm-system-settings (otherwise there is another timeout at shutdown)
- wpa_supplicant (if the connection is wireless)
- dbus (otherwise it will kill wpa_supplicant when killed)
- dhclient (for DHCP connections)

Then umountnfs.sh runs, then we should really kill the remaining processes.

There are two ways of doing it, making the sysv-initscripts aware of the
issue (teaching S20sendsigs to avoid network stuff and adding a
S35reallysendsigs that doesn't avoid anything), or doing it in
initscripts in each package by adding sendsigs.omit.d items and pushing
S35 scripts in rc0/rc6 to really kill them (slightly more complex since
it touches multiple packages and in most cases - wpa_supplicant,
dhclient, nm-system-settings - they are not started or stopped by an
init script).

Please let me know how do you think we should proceed to fix this.

--
Thierry Carrez
Ubuntu server team

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 03-16-2009, 03:24 PM
Scott James Remnant
 
Default Shutdown sequence and Network filesystems

On Mon, 2009-03-16 at 15:14 +0100, Thierry Carrez wrote:

> To cut those long threads short, the problem is that on
> NetworkManager-enabled systems, we kill networking at S20sendsigs,
> before S31umountnfs.sh. This leads to various timeout errors in
> umountnfs.sh and potentially to data loss on the network filesystems.
>
Since Network Manager, and D-Bus, and HAL, and various other bits of
that stack are in /usr - it's kinda hard to *not* kill them and
have /usr-on-NFS work.

Scott
--
Scott James Remnant
scott@canonical.com
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 03-16-2009, 09:54 PM
Steve Langasek
 
Default Shutdown sequence and Network filesystems

On Mon, Mar 16, 2009 at 04:24:43PM +0000, Scott James Remnant wrote:
> On Mon, 2009-03-16 at 15:14 +0100, Thierry Carrez wrote:

> > To cut those long threads short, the problem is that on
> > NetworkManager-enabled systems, we kill networking at S20sendsigs,
> > before S31umountnfs.sh. This leads to various timeout errors in
> > umountnfs.sh and potentially to data loss on the network filesystems.

> Since Network Manager, and D-Bus, and HAL, and various other bits of
> that stack are in /usr - it's kinda hard to *not* kill them and
> have /usr-on-NFS work.

It's also kinda hard to have /usr-on-NFS work at all if you're using Network
Manager to manage that connection, though.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 03-17-2009, 06:48 AM
Thierry Carrez
 
Default Shutdown sequence and Network filesystems

Steve Langasek wrote:
> On Mon, Mar 16, 2009 at 04:24:43PM +0000, Scott James Remnant wrote:
>> On Mon, 2009-03-16 at 15:14 +0100, Thierry Carrez wrote:
>
>>> To cut those long threads short, the problem is that on
>>> NetworkManager-enabled systems, we kill networking at S20sendsigs,
>>> before S31umountnfs.sh. This leads to various timeout errors in
>>> umountnfs.sh and potentially to data loss on the network filesystems.
>
>> Since Network Manager, and D-Bus, and HAL, and various other bits of
>> that stack are in /usr - it's kinda hard to *not* kill them and
>> have /usr-on-NFS work.
>
> It's also kinda hard to have /usr-on-NFS work at all if you're using Network
> Manager to manage that connection, though.

Exactly, you can't really have network maintained by bits in /usr and
/usr on NFS either. I think on NM-enabled desktops, the use case of
mounting a samba share from your music library NAS is more common than
having /usr-on-NFS, and keeping one broken to make sure the other is
properly handled might not be the best response...

If we agree that we can't have both /usr-on-NFS and NetworkManager at
the same time, then the proposed S20sendsigs could detect the two use
cases and act accordingly. If we want to keep the old behavior in all
cases, then I'd argue an option in /etc/default/rcS could be used to
trigger the new behavior (keep selected network-maintaining processes
alive until umountnfs.sh completes).

Or maybe I just missed a more elegant way of fixing it for all use cases ?

Another related bug is openvpn bug 41794, VPN tunnel is closed before
network drives are unmounted when shutting down.

--
Thierry Carrez
Ubuntu server team || Canonical Ltd.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 03-17-2009, 09:13 AM
Scott James Remnant
 
Default Shutdown sequence and Network filesystems

On Tue, 2009-03-17 at 08:48 +0100, Thierry Carrez wrote:

> Exactly, you can't really have network maintained by bits in /usr and
> /usr on NFS either. I think on NM-enabled desktops, the use case of
> mounting a samba share from your music library NAS is more common than
> having /usr-on-NFS, and keeping one broken to make sure the other is
> properly handled might not be the best response...
>
I'm not sure I agree with this.

Network Manager is aimed sufficiently at the desktop case that accessing
things like samba shares are more likely to be handled via the GVfs
layer (ie. smb:/// in nautilus) than by making mounts.

Scott
--
Scott James Remnant
scott@canonical.com
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 03-18-2009, 07:22 AM
Thierry Carrez
 
Default Shutdown sequence and Network filesystems

Scott James Remnant wrote:
> On Tue, 2009-03-17 at 08:48 +0100, Thierry Carrez wrote:
>
>> Exactly, you can't really have network maintained by bits in /usr and
>> /usr on NFS either. I think on NM-enabled desktops, the use case of
>> mounting a samba share from your music library NAS is more common than
>> having /usr-on-NFS, and keeping one broken to make sure the other is
>> properly handled might not be the best response...
>>
> I'm not sure I agree with this.
>
> Network Manager is aimed sufficiently at the desktop case that accessing
> things like samba shares are more likely to be handled via the GVfs
> layer (ie. smb:/// in nautilus) than by making mounts.

Yes, I tend to agree with you. That was part of my question on what use
cases we should support for mounting network filesystems.

If the general consensus here is that we don't support mounting network
filesystems (through classic mounts) when networking is handled by
session-related tools like NetworkManager, then those bugs should just
be closed as wontfix.

The two supported use cases would be:
- Define your connection in /etc/network/interfaces rather than
NetworkManager -> use whatever you want
- use NetworkManager to manage your connection -> only use gvfs mounts

That means we should concentrate on fixing gvfs support in most desktop
applications (think bug 273294, "Rhythmbox can not use smb:// as library
location"), rather than hardcoding workarounds in the shutdown sequence.

Cheers,

--
Thierry Carrez
Ubuntu server team || Canonical Ltd.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 03-18-2009, 07:39 AM
Oliver Grawert
 
Default Shutdown sequence and Network filesystems

hi,
Am Dienstag, den 17.03.2009, 10:13 +0000 schrieb Scott James Remnant:
> On Tue, 2009-03-17 at 08:48 +0100, Thierry Carrez wrote:
>
> > Exactly, you can't really have network maintained by bits in /usr and
> > /usr on NFS either. I think on NM-enabled desktops, the use case of
> > mounting a samba share from your music library NAS is more common than
> > having /usr-on-NFS, and keeping one broken to make sure the other is
> > properly handled might not be the best response...
> >
> I'm not sure I agree with this.
>
> Network Manager is aimed sufficiently at the desktop case that accessing
> things like samba shares are more likely to be handled via the GVfs
> layer (ie. smb:/// in nautilus) than by making mounts.
well, there are a lot of ltsp users out there using AD servers for
authentication and pulling off /home/$USER via CIFS from their AD
server ...

should we special-case NM to not start up at all if the ltsp-server
package is present or any kind of AD auth is used (that would be wrong
imho, sinbce you might just have ltsp for demo or test purposes
installed on your laptop, but i see no other option)

ciao
oli
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 03-18-2009, 08:51 AM
Scott James Remnant
 
Default Shutdown sequence and Network filesystems

On Wed, 2009-03-18 at 09:22 +0100, Thierry Carrez wrote:

> If the general consensus here is that we don't support mounting network
> filesystems (through classic mounts) when networking is handled by
> session-related tools like NetworkManager, then those bugs should just
> be closed as wontfix.
>
I think we need to decide whether or not we do want to support them. If
we do, we should look strongly at restructuring the way we unmount
filesystems.

Scott
--
Scott James Remnant
scott@canonical.com
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 03-18-2009, 03:19 PM
George Farris
 
Default Shutdown sequence and Network filesystems

On Wed, 2009-03-18 at 09:39 +0100, Oliver Grawert wrote:
> hi,
> Am Dienstag, den 17.03.2009, 10:13 +0000 schrieb Scott James Remnant:
> > On Tue, 2009-03-17 at 08:48 +0100, Thierry Carrez wrote:
> >
> > Network Manager is aimed sufficiently at the desktop case that accessing
> > things like samba shares are more likely to be handled via the GVfs
> > layer (ie. smb:/// in nautilus) than by making mounts.
> well, there are a lot of ltsp users out there using AD servers for
> authentication and pulling off /home/$USER via CIFS from their AD
> server ...
>
> should we special-case NM to not start up at all if the ltsp-server
> package is present or any kind of AD auth is used (that would be wrong
> imho, sinbce you might just have ltsp for demo or test purposes
> installed on your laptop, but i see no other option)

Yes and I have companies with the desktop installed and mounting /home
via NFS. This works quite well, and blows roaming profiles in the
Windows world all to hell, for the most part.

Cheers



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 03-18-2009, 05:35 PM
Steve Langasek
 
Default Shutdown sequence and Network filesystems

On Mon, Mar 16, 2009 at 03:14:34PM +0100, Thierry Carrez wrote:
> There are three ways of handling your network:

> 1- Without using NetworkManager
> Then everything works fine

> 2- With Networkmanager with connection in "Available for all users" mode
> S20sendsigs kills NetworkManager, dhclient and wpasupplicant, resulting
> in loss of network connection. S31umountnfs.sh fails with various
> timeouts/errors.

> 3- With NetworkManager with connection in default mode (per-user)
> When Gnome session is terminated, the network connection is killed... by
> design. So umountnfs.sh fails as well.

> Should we support option (3), mounting network filesystems on a network
> connection in per-user mode ? It seems bound to failure by design. At
> that point I would say it probably makes sense to fix it for option (2)...

There was some impromptu discussion on IRC yesterday about this, and it was
suggested to explore whether this could be handled using a default interface
if-down.d script. The script would have to:

- determine the IP address of the network mount
- establish that this interface is the only interface providing the route
used for the mount
- do something sensible <handwave> if the mount point is still in use

That would mostly address case 3, but may give unpleasant results in the
event of a weak wireless signal or due to roaming between multiple APs,
since AFAIK NM will take down the IP configuration whenever it loses
association. We probably don't want network mounts to automatically come
undone whenever this happens. (OTOH, it would certainly be nice if
something sensible was done with NFS mounts that I've left mounted before
suspending, and resumed in a completely different network.)

Regardless, my understanding is that the biggest problem with unmounting
network mounts when the network is already gone is with CIFS mounts. We
should not have to wait for a network timeout on unmount when the network is
demonstrably Not There; this is a bug in the CIFS kernel driver that should
be fixed, regardless of any other changes.

On Tue, Mar 17, 2009 at 10:13:50AM +0000, Scott James Remnant wrote:
> On Tue, 2009-03-17 at 08:48 +0100, Thierry Carrez wrote:

> > Exactly, you can't really have network maintained by bits in /usr and
> > /usr on NFS either. I think on NM-enabled desktops, the use case of
> > mounting a samba share from your music library NAS is more common than
> > having /usr-on-NFS, and keeping one broken to make sure the other is
> > properly handled might not be the best response...

> I'm not sure I agree with this.

> Network Manager is aimed sufficiently at the desktop case that accessing
> things like samba shares are more likely to be handled via the GVfs
> layer (ie. smb:/// in nautilus) than by making mounts.

I think that's less about NetworkManager's aim than its reach. Certainly,
some past comments from Alexander suggest that the long-term goal is to
supplant ifupdown rather than to coexist with it.

And kernel-level cifs mounts may be a minority use case, but we still should
account for them in our design, because it's a very *significant* minority
use case, particularly for large site deployments with central fileservers
for user data. gvfs smb:// doesn't help very much for getting the user's
homedir mounted.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 

Thread Tools




All times are GMT. The time now is 09:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org