After the last major update (about a week ago) automount crashes after about 20 minutes is running.
I have started the daemon manually and this is the output from start to crash:
Starting automounter version 5.1.3, master map auto.master
using kernel protocol version 5.02
lookup(yp): read of master map auto.master failed: Can’t bind to server which serves this domain
lookup(file): failed to read included master map auto.master
lookup(yp): read of master map auto.master failed: Can’t bind to server which serves this domain
lookup(file): failed to read included master map auto.master
ignoring duplicate indirect mount /net
ignoring duplicate indirect mount /home
lookup(yp): read of master map auto.master failed: Can’t bind to server which serves this domain
lookup(file): failed to read included master map auto.master
master_add_map_source: map source used without taking reference
master_add_map_source: map source used without taking reference
lookup(yp): read of master map auto.master failed: Can’t bind to server which serves this domain
lookup(file): failed to read included master map auto.master
master_add_map_source: map source used without taking reference
master_add_map_source: map source used without taking reference
lookup(yp): read of master map auto.master failed: Can’t bind to server which serves this domain
lookup(file): failed to read included master map auto.master
master_add_map_source: map source used without taking reference
master_add_map_source: map source used without taking reference
lookup(yp): read of master map auto.master failed: Can’t bind to server which serves this domain
lookup(file): failed to read included master map auto.master
master_add_map_source: map source used without taking reference
master_add_map_source: map source used without taking reference
problem reading master map, maximum wait exceeded
automount: warning: could not read at least one map source after waiting, continuing …
lookup(yp): read of master map auto.master failed: Can’t bind to server which serves this domain
lookup(file): failed to read included master map auto.master
master_add_map_source: map source used without taking reference
master_add_map_source: map source used without taking reference
mounted indirect on /net with timeout 300, freq 75 seconds
mounted indirect on /home with timeout 300, freq 75 seconds
attempting to mount entry /home/cesare
set_tsd_user_vars: failed to get group info from getgrgid_r
lookup(yp): lookup for cesare failed: Internal NIS error
Segmentation fault (core dumped)
Does anybody have a similar issue? I have not changed anything in the configuration files, this has been working fine for over 1 year since I have installed Tumbleweed.
Looks to me that you are trying to mount a remote network share, and a connection to the remote server failed.
So,
Troubleshoot your network connection…
Server down?
Physical network problems?
If the network share requires name resolution, is it working?
And,
You’re supposed to post your data output in
tags (When using the web tool to access these forums, it's the button with the hash (#)
That can make your data easier to read, particularly if your post includes detailed description.
TSU
I was not aware on how to post data output, thank you for pointing that out.
Name resolution is working.
Server is up and running.
There are no network problems since the other static mounted NFS partition on the same server have no issues.
The home directories do mount just fine, and keep on working for about 20 minutes, until then the automount daemon pops a core dump and crashes.
This had been working fine for over a year and only started 2-3 updates ago. I have not made any change on the environment over the past few months, a part than from patching regularly my servers.
I like the tumbleweed distribution concept, but quite frankly Leap is way more stable. Six months ago I had the kernel panicking and crashing the server after a few hours, then after a few months of updates it eventually was fixed.
This may be a good distribution for development and testing, not so sure for production…
I have nearly the same problem: autofs crashes with segmentation fault during the system start. If I restart it, it crashes after the first try to access a network directory:
During the system start:
Sep 07 17:19:55 gibib28 kernel: automount[1803]: segfault at 7f0c5d6ec620 ip 00007f0c5d13fba0 sp 00007f0c59ecc288 error 4 in libcrypto.so.1.0.0[7f0c5d013000+240000]
Sep 07 17:19:55 gibib28 systemd[1]: Started Process Core Dump (PID 1804/UID 0).
Sep 07 17:19:55 gibib28 systemd[1]: autofs.service: Main process exited, code=killed, status=11/SEGV
Sep 07 17:19:55 gibib28 systemd[1]: autofs.service: Unit entered failed state.
Sep 07 17:19:55 gibib28 systemd[1]: autofs.service: Failed with result 'signal'.
Sep 07 17:19:55 gibib28 systemd-coredump[1805]: Process 1383 (automount) of user 0 dumped core.
After restart with systemctl restart autofs:
Sep 08 09:09:46 gibib28 systemd[1]: Starting Automounts filesystems on demand...
Sep 08 09:09:46 gibib28 systemd[1]: Started Automounts filesystems on demand.
Sep 08 09:11:32 gibib28 kernel: automount[7033]: segfault at 7fbb26721620 ip 00007fbb26174ba0 sp 00007fbb1eeff288 error 4 in libcrypto.so.1.0.0[7fbb26048000+240000]
Sep 08 09:11:32 gibib28 systemd[1]: Started Process Core Dump (PID 7034/UID 0).
Sep 08 09:11:32 gibib28 systemd[1]: autofs.service: Main process exited, code=killed, status=11/SEGV
Sep 08 09:11:32 gibib28 systemd[1]: autofs.service: Unit entered failed state.
Sep 08 09:11:32 gibib28 systemd[1]: autofs.service: Failed with result 'signal'.
Sep 08 09:11:32 gibib28 systemd-coredump[7035]: Process 6963 (automount) of user 0 dumped core.
The problem happens first after a zypper dup. All other many clients a our site are working without any flaw.
If I leave a console on with current path on one of the automounted home dirs the autofs does not crash. It would seem the issue to be when the filesystem gets auto unmounted due to inactivity?
In the meantime updates for the crypto library were released but still crashes…
