Autofs should be reloaded when state of network interface changes

I forget to mention the Ubuntu version. It's on feisty fawn.

Due to this issue, an update of feisty to gutsy this breaks the expected behavior on NIS clients. I've just updated 3 workstations to gutsy and each needs autofs to be restarted after boot for users to be able to log on if they have non-local home folders.

This is still an issue in Hardy. Currently, NetworkManager is set to "roaming" by default. NIS works fine, but autofs does not. I have to login as the local admin and restart the service before I can login with my NIS user. My experience with Fedora 8 said that to fix this, you need to disable roaming for the wired connection and set it to DHCP. However, under Hardy, the system locks up and I was forced to power it off to get the system back. Roaming makes sense for systems with more then one ethernet device, but a desktop with a single ethernet device, roaming causes problems if that system is supposed to use a network authetication/home directory setup such as NIS/AUTOFS, etc.

It seems that the NetworkManager is not quite right under Ubuntu 8.04. On Fedora 8, NIS would not work at all out of the box due to the network connection not being established until a user logged in. If you disable roaming and set it to use DHCP everything works as expected. Ubuntu 8.04, NIS works with NetworkManager set to roaming however disabling it causes the networking to not work at all. I get no IP address, ifconfig can't seem to bring up the eth0 device and the system locks up after attempting to bring up the eth0 connection.

I can try and gather more information upon request as I'd love this to be fixed.

Still a problem on 8.10

This seems to be an issue on some distributions (hardy 8.04) we have installed.

Andreas: does the script you mentioned need a predefined name? adding your script does not seem to solve the issue on a hardy 8.04 (installed on a HP dc7900 UFF).

I no longer need this script and i'm using intrepid 8.10 on all my machines.
The script i posted almost 2 years ago does require a special name. you only have to mark the script as executeable (chmod 0755 scriptname).

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

i no longer have any problem with autofs. thanks.

This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status . Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

This is still a problem for the LTS (Hardy). The workstations I'm installing on need to be relatively stable and undergo major updates rarely, so if I can avoid it non LTS installs I will.

Is it known if this is a problem in Jaunty, I do not use workstations/servers so I don't know how to check if this is working in Jaunty or not. If it is, it *may* be able to be backported.

Doesn't work for me in Ubuntu 9.04 with LDAP backend, I have to restart autofs after reboot manually.

switching back to new

Hi,

Is this still an issue on karmic?

Regards
chuck

Yes

I can confirm that this is an issue for Karmic.

This is marked as a low-importance bug. For stand-alone systems I can see how this would be the case. But for an integrated environment that relies on LDAP and AutoFS to provide user support, this bug prevents users from being able to log in on their workstation.

For me, adding the above script to /etc/network/if-up.d/ didn't work. But I was able to address the issue with the following horrible kludge. Since this whole problem will likely be addressed via the new upstart paradigm, I thought I would base my fix on upstart. It could just as easily be put into an init.d script instead.

file: /etc/init/fix-autofs.conf
---------------------------------------------
# fix-autofs - Check for and fix LDAP/AutoFS race condition error
#
# When NIS or LDAP is used in conjunction with AutoFS a race condition is
# introduced into the system where, when AutoFS is started before the network
# is completely up, AutoFS will exit, as it won't be able to find any of it's
# configuration information.

description "AutoFS/LDAP Race Condition Fix"

start on runlevel [2345]

task
script
  #
  # Using ldapsearch here to pass the time until LDAP binding is up.
  # Edit the search term 'ou=automount' to taste...
  #
  while ! /usr/bin/ldapsearch -xLLL 'ou=automount' > /dev/null 2>&1 ; do
    echo "Waiting for LDAP to bind..."
    sleep 1
  done
  if ! /usr/bin/pgrep automount > /dev/null 2>&1 ; then
    echo "AutoFS is not running, attempting to start..."
    #
    # Seriously? Using an upstart script to call invoke-rc.d?
    # Yes. There is no upstart configuration file for autofs (yet).
    #
    /usr/sbin/invoke-rc.d autofs restart
  fi
end script

FWIW, the /etc/network/if-up.d/ does work for me. I hope this can get fixed soon. I'm also having a similar problem with the openssh-server... sshd does not fire off at boot, I have to start manually even though it's turned on in chkconfig and the /ect/init.d script looks good. Not sure what's going on there...

Upgrading status to Medium. The severity could have quite a big usability issue with workstations, but in this case does not warrant High status, as the bug itself would not affect many regular users. Thank you.

Thanks for upgrading... I should mention we're using in a university lab setting with about 40 workstations for students whose accounts are accessed via NIS... I've implemented the script fix so we're probably okay...you're right this probably affects a relatively small number of users...

Hello,

I see a similar problem on Karmic when using autofs to mount CIFS shares. If I turn off my computer while a share is still mounted, the computer will stay upon "killing all remaining process line" indefinitely. If I add a script similar to the one proposed in "/etc/network/if-down.d" to umount automounted shares, my computer will nicely shut down every time. I think that networkmanager brings ethernet interface down before autofs is called to umount shares.

Guillaume

We've got 200 workstations for students, doctors, postdocs, professors and employees... the ugly hack on top works, however it's not the right solution, is it?

Gürkan Sengün wrote:
> We've got 200 workstations for students, doctors, postdocs, professors
> and employees... the ugly hack on top works, however it's not the right
> solution, is it?
>

There's already a precedent set by other services to include scripts in
if-up.d/ and if-down.d/ to manage themselves in the event of a network
state change, so I would say that this approach is kosher enough to call
it correct. (It just didn't work for me, and I couldn't tell you why
not, so I implemented my horrible kludge instead and it works like a charm.)

I can also see that there are upstart scripts in if-up.d/ and if-down.d/
that emit "net-device-up" and "net-device-down", respectively, as a
result of a network state change. The problem is that autofs is still
started via an /etc/init.d script, and not by upstart, so these signals
may not have any bearing on the state of autofs. But given Ubuntu's
move to upstart I would image that future versions of autofs-ldap will
include an /etc/init/ upstart script that is smart enough to make use of
these signals and manage things properly.

...But as a thought experiment, I think it would be a bad idea for
services like autofs to listen directly for a "net-device-*" signal.
Systems with multiple network interfaces may, depending on their use,
bring network interfaces up and down often that would have no effect at
all on the state of their directory service or the ability for autofs to
function correctly.

Perhaps the proper solution, then, should also involve modifying the
LDAP and NIS packages to include functionality that will specifically
emit their own up or down signals, but only in the event that the
associated network interface through which directory services are bound
change state.

For instance, let's say that a system has six network interfaces: eth0
through eth5. The system is bound (via LDAP or NIS) to a server that is
only available via the eth3 interface. You don't want autofs to shut
itself down whenever it sees a "net-device-down" signal, because unless
that signal is in response to bringing eth3 down then directory binding
would continue to work properly.

The LDAP (or NIS) package could include an upstart script that listens
for "net-device-up" and "net-device-down" signals. When one is
received, check the connection to the directory server (be it LDAP or
NIS). If "net-device-down" was received and the the directory server is
now unreachable, then a "directory-binding-down" should be emitted.
Likewise, if a "net-device-up" signal was seen, then a timeout should be
started where the upstart script waits for directory binding to
succeed. If it does, then a "directory-binding-up" should be emitted.
If it times out first, emit "directory-binding-down".

Other services that rely on directory binding, such as the autofs-ldap
package, could listen specifically for the "directory-binding-down" and
"directory-binding-up" signals and know that it is now okay to take
appropriate action.

(...There's probably a better way to handle this, but this was an
off-the-hip shot.)

Michael

Uggh it really seems like Ubuntu doesn't give a crap about nis using folks. This is the last straw for me.

This bug has been marked Triaged and forwarded to Debian. All further information that you can provide should be sent there to avoid confusion between the 2 bug trackers. Thank you.

Since this still appears to be an issue on Trusty (14.04) and the Debian bugtracker notes that they're no longer tracking autofs in unstable, what happens to this bug?

And is it still the case that autofs (now version 5 in Trusty's repo's) doesn't use upstart? I'm going to try the solution presented in the bug description, but is that workaround still the most appropriate fix for what seems to be a pretty glaring ommision in autofs functionality?

How do corporates join their laptops to their network shares over WIFI reliably when autofs is effectively broken in this case?