Once the system gets into this state, the only remedy is a forced power-off. What seems to be happening is that an NFS filesystem that auto-mounted over a WiFi connection cannot be unmounted because the WiFi connection is enabled only for my login and gets torn down when my UID is logged off.
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
On 08/30/2015 04:20 PM, Robert Nichols wrote:
Once the system gets into this state, the only remedy is a forced power-off. What seems to be happening is that an NFS filesystem that auto-mounted over a WiFi connection cannot be unmounted because the WiFi connection is enabled only for my login and gets torn down when my UID is logged off.
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
Oops, forgot to mention that this is CentOS 6.7.
On Sun, 30 Aug 2015 16:20:21 -0500 Robert Nichols wrote:
Once the system gets into this state, the only remedy is a forced power-off. What seems to be happening is that an NFS filesystem that auto-mounted over a WiFi connection cannot be unmounted because the WiFi connection is enabled only for my login and gets torn down when my UID is logged off.
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
Perhaps you could unmount that share when you log off by putting a umount command into the appropriate file.
The definition of "appropriate file" varies depending on what DE you're using.
On 08/30/2015 04:32 PM, Frank Cox wrote:
On Sun, 30 Aug 2015 16:20:21 -0500 Robert Nichols wrote:
Once the system gets into this state, the only remedy is a forced power-off. What seems to be happening is that an NFS filesystem that auto-mounted over a WiFi connection cannot be unmounted because the WiFi connection is enabled only for my login and gets torn down when my UID is logged off.
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
Perhaps you could unmount that share when you log off by putting a umount command into the appropriate file.
The definition of "appropriate file" varies depending on what DE you're using.
Thanks for the suggestion. I'm using Gnome, and created an executable file /etc/gdm/PostSession/autofsNFS containing:
#!/bin/bash if grep -q ':.* nfs[234]? ' /proc/mounts; then if [ -r /var/run/autofs.pid ]; then Pid=$(</var/run/autofs.pid) [ -n "$Pid" ] && kill -USR1 $Pid fi fi
That sends a SIGUSR1 to the automount process if there are any remote NFS mounts listed in /proc/mounts. It seems to do the trick.
On 08/31/2015 10:32 AM, Robert Nichols wrote:
On 08/30/2015 04:32 PM, Frank Cox wrote:
Perhaps you could unmount that share when you log off by putting a umount command into the appropriate file.
The definition of "appropriate file" varies depending on what DE you're using.
Thanks for the suggestion. I'm using Gnome, and created an executable file /etc/gdm/PostSession/autofsNFS containing:
#!/bin/bash if grep -q ':.* nfs[234]? ' /proc/mounts; then if [ -r /var/run/autofs.pid ]; then Pid=$(</var/run/autofs.pid) [ -n "$Pid" ] && kill -USR1 $Pid fi fi
That sends a SIGUSR1 to the automount process if there are any remote NFS mounts listed in /proc/mounts. It seems to do the trick.
Weird! That should not have worked since that file never gets executed. Apparently the problem is less repeatable than I thought.
I put that code into the /etc/gdm/PostSession/Default script, where it actually gets executed and immediately runs into SELinux issues. I ran audit2allow on all the AVC denials, and now the script runs properly and, again, seems to fix the issue. Final verdict on that is still pending, though.
Note that /etc/gdm/PostSession/Default is marked as a configuration file in the gdm RPM, and so should not get wiped out by an update.
On 8/30/2015 2:20 PM, Robert Nichols wrote:
Once the system gets into this state, the only remedy is a forced power-off. What seems to be happening is that an NFS filesystem that auto-mounted over a WiFi connection cannot be unmounted because the WiFi connection is enabled only for my login and gets torn down when my UID is logged off.
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
my experience is A) NFS doesn't like unreliable networks, and B) WiFi isn't very reliable.
perhaps using the 'soft' mount option will help, along with intr ?
On 08/30/2015 04:45 PM, John R Pierce wrote:
On 8/30/2015 2:20 PM, Robert Nichols wrote:
Once the system gets into this state, the only remedy is a forced power-off. What seems to be happening is that an NFS filesystem that auto-mounted over a WiFi connection cannot be unmounted because the WiFi connection is enabled only for my login and gets torn down when my UID is logged off.
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
my experience is A) NFS doesn't like unreliable networks, and B) WiFi isn't very reliable.
perhaps using the 'soft' mount option will help, along with intr ?
Making use of the "intr" option would require that the umount process have the console as its controlling tty. AFAICT, having been invoked from the init process, it has _no_ controlling tty. Hard to send a SIGINT that way.
Really, I don't think the problem is specific to WiFi. I believe I'd run into the same thing for any network connection that was not marked "Available to all users" in NetworkManager.
On 08/31/2015 02:15 AM, Robert Nichols wrote:
On 08/30/2015 04:45 PM, John R Pierce wrote:
On 8/30/2015 2:20 PM, Robert Nichols wrote:
Once the system gets into this state, the only remedy is a forced power-off. What seems to be happening is that an NFS filesystem that auto-mounted over a WiFi connection cannot be unmounted because the WiFi connection is enabled only for my login and gets torn down when my UID is logged off.
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
my experience is A) NFS doesn't like unreliable networks, and B) WiFi isn't very reliable.
perhaps using the 'soft' mount option will help, along with intr ?
Making use of the "intr" option would require that the umount process have the console as its controlling tty. AFAICT, having been invoked from the init process, it has _no_ controlling tty. Hard to send a SIGINT that way.
The "intr" option is no longer available. See the nfs man page: "This option is provided for backward compatibility. It is ignored after kernel 2.6.25."
You should be able to kill -9 the process though.
Regards, Dennis
On 08/31/2015 05:22 AM, Dennis Jacobfeuerborn wrote:
On 08/31/2015 02:15 AM, Robert Nichols wrote:
On 08/30/2015 04:45 PM, John R Pierce wrote:
On 8/30/2015 2:20 PM, Robert Nichols wrote:
Once the system gets into this state, the only remedy is a forced power-off. What seems to be happening is that an NFS filesystem that auto-mounted over a WiFi connection cannot be unmounted because the WiFi connection is enabled only for my login and gets torn down when my UID is logged off.
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
my experience is A) NFS doesn't like unreliable networks, and B) WiFi isn't very reliable.
perhaps using the 'soft' mount option will help, along with intr ?
Making use of the "intr" option would require that the umount process have the console as its controlling tty. AFAICT, having been invoked from the init process, it has _no_ controlling tty. Hard to send a SIGINT that way.
The "intr" option is no longer available. See the nfs man page: "This option is provided for backward compatibility. It is ignored after kernel 2.6.25."
You should be able to kill -9 the process though.
The problem occurs late in the shutdown sequence. There is no shell available for entering a "kill" command.
On Sun, Aug 30, 2015 at 04:20:21PM -0500, Robert Nichols wrote:
Once the system gets into this state, the only remedy is a forced power-off. What seems to be happening is that an NFS filesystem that auto-mounted over a WiFi connection cannot be unmounted because the WiFi connection is enabled only for my login and gets torn down when my UID is logged off.
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
I didn't think that making the connection available to all users had security ramifications regarding your wifi password... if someone else logs in and uses the wifi, they still need the root password to access the wireless configuration, don't they?
Fred
On Sun, Aug 30, 2015 at 04:20:21PM -0500, Robert Nichols wrote:
Any suggestions on how I can configure things to avoid this? I really don't want to expose my WPA2 key by making the connection available to all users.
How are you mounting the volume? Are you using autofs?
-
Dennis Jacobfeuerborn -
Frank Cox -
Fred Smith -
John R Pierce -
Jonathan Billings -
Robert Nichols