Thanks for the report. Assigning to maintainer.

Assignee: bugsquad => shlomif
Keywords: (none) => Junior_job

Confirmed.

This is indeed having effect for people upgrading from Mageia 4 to Mageia 5 and who are not aware of the need to change this configuration.
Could be added to the Errata or the Release Notes.


For documentation purpose, the observed effect is a segmentation fault:

# systemctl status autofs.service
â autofs.service - Automounts filesystems on demand
   Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled)
   Active: failed (Result: signal) since sam. 2015-08-15 12:17:18 CEST; 13min ago
 Main PID: 1705 (code=killed, signal=SEGV)

août 15 12:11:26 turion systemd[1]: Started Automounts filesystems on demand.
août 15 12:17:18 turion systemd[1]: autofs.service: main process exited, code=killed, status=11/SEGV
août 15 12:17:18 turion systemd[1]: Unit autofs.service entered failed state.
août 15 12:17:18 turion systemd[1]: autofs.service failed.
août 15 12:30:54 turion systemd[1]: Stopped Automounts filesystems on demand.



Steps to reproduce:

1] Run the command directly as root in a terminal

# /usr/sbin/automount -dvf --pid-file /run/autofs.pid                     
Starting automounter version 5.1.0, master map auto.master
using kernel protocol version 5.02
lookup_nss_read_master: reading master files auto.master
parse_init: parse(sun): init gathered global options: (null)
lookup_read_master: lookup(file): read entry +dir:/etc/auto.master.d
lookup_nss_read_master: reading master dir /etc/auto.master.d
lookup_read_master: lookup(dir): scandir: /etc/auto.master.d
include_file: lookup(dir): include: /etc/auto.master.d/net_hosts.autofs
lookup_nss_read_master: reading master file /etc/auto.master.d/net_hosts.autofs
parse_init: parse(sun): init gathered global options: (null)
lookup_read_master: lookup(file): read entry /net
lookup_read_master: lookup(file): read entry +auto.master
lookup_nss_read_master: reading master files auto.master
parse_init: parse(sun): init gathered global options: (null)
lookup(file): failed to read included master map auto.master
master_do_mount: mounting /net
automount_path_to_fifo: fifo name /run/autofs.fifo-net
lookup_nss_read_map: reading map hosts (null)
parse_init: parse(sun): init gathered global options: (null)
lookup_read_map: lookup(hosts): read hosts map
lookup_read_map: lookup(hosts): map not browsable, update existing host entries only
remount_active_mount: trying to re-connect to mount /net
mounted indirect on /net with timeout 300, freq 75 seconds
remount_active_mount: re-connected to mount /net
st_ready: st_ready(): state = 0 path /net


2] In another terminal, as any user, try to access the remote host (here qnapnas) which still uses NFS v3.

$ ls -la /net/qnapnas/


3] Switch back to the first terminal, this is then visible:

handle_packet: type = 3
handle_packet_missing_indirect: token 5, name qnapnas, request pid 4982
attempting to mount entry /net/qnapnas
lookup_mount: lookup(hosts): qnapnas -> (null)
get_exports: lookup(hosts): fetchng export list for qnapnas
Erreur de segmentation (core dumped)


The proposed update from Davy Defaud solved the problem.

CC: (none) => balsacq

(In reply to Davy Defaud from comment #0)
> AutoFS default master file /etc/autofs/auto.master includes some commented
> lines for special hosts and misc maps. These entries are outdated:
> 
> /net	-hosts
> /misc	/etc/auto.misc
> 
> Since AutoFS 5+, they should be replaced by:
> 
> /net	/etc/autofs/auto.net	--timeout=60
> /misc	/etc/autofs/auto.misc
> 
> 

Sorry for the late response, but these lines appear as they are in autofs-5.1.1/samples/auto.master in the autofs distribution , so this should be reported upstream.

I'll try to see if I can report it there.

Regards,

-- Shlomi Fish

> 
> Reproducible: 
> 
> Steps to Reproduce:

> 
> Sorry for the late response, but these lines appear as they are in
> autofs-5.1.1/samples/auto.master in the autofs distribution , so this should
> be reported upstream.
> 
> I'll try to see if I can report it there.
> 

Unfortunately the mailing list for autofs is hosted on the @vger.kernel.org E-mail domain and I am blocked from there. So someone here will have to report it instead.

Regards,

-- Shlomi

Unfortunately, using /etc/autofs/auto.net instead of "-host" doesnât work with NFSv4 :-(
The reason is that auto.net script is using "showmount -e" to list the available exported filesystems on the NFS server, but this command doesnât work with NFSv4.
However showmount is working with NFSv4 with a CentOS 7 client, *apparently* thanks to a new daemon named gssproxy (https://fedoraproject.org/wiki/Features/gss-proxy)...

Hi Davy,

Thank you for having taken the needed time to report this issue!

Did this bug get fixed? If so, please change its status to RESOLVED - FIXED

If it didn't, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/
It only continued to get important security updates since then, because we are waiting for a big Plasma5 update in Mageia 6, that'll fix many of the Mageia 5 => 6 upgrade issues.

If you haven't seen that this bug got fixed, then please check whether this bug still exists in Mageia 6. If it does, then please change the Version (near the top, at the left) to "6". If you know it exists in Cauldron, then change Version to Cauldron. If you see it in both Cauldron and Mageia 6, then please set Version to Cauldron and add MGA6TOO on the Whiteboard.

Also, Davy, if it's still valid: did you report it upstream?

Thanks,
Marja

Keywords: Junior_job => UPSTREAM
CC: (none) => marja11

> Did this bug get fixed? If so, please change its status to RESOLVED - FIXED
> […] 
> If you haven't seen that this bug got fixed, then please check whether this
> bug still exists in Mageia 6.

Well, it is almost resolved. “/net -hosts” in /etc/autofs/auto.master works again, but auto.misc has been moved from /etc to /etc/autofs, so the commented entry for this map in /etc/autofs/auto.master should be updated accordingly.

> If it does, then please change the Version
> (near the top, at the left) to "6". If you know it exists in Cauldron, then
> change Version to Cauldron. If you see it in both Cauldron and Mageia 6,
> then please set Version to Cauldron and add MGA6TOO on the Whiteboard.

Done

> 
> Also, Davy, if it's still valid: did you report it upstream?

The latest tarball at https://mirrors.edge.kernel.org/pub/linux/daemons/autofs/v5/ contains an RPM spec file. In the spec file I can see that the map files are still located in /etc. So, I guess that we are using a different policy (which I prefer) of moving map files in a dedicated directory /etc/autofs/. Now, we should also update the master map to match that change.

> 
> Thanks,
> Marja

You’re welcome Marja

Davy

Version: 5 => Cauldron
Whiteboard: OK => OK MGA6TOO

On Mageia 7
For autofs-5.1.5-1.mga7.src.rpm, /etc/autofs/auto.master still has:
 #/misc  /etc/auto.misc
> auto.misc has been moved from /etc to /etc/autofs, so the commented entry
> for this map in /etc/autofs/auto.master should be updated accordingly
Still applies.

When installing the package:
"setup
-----
Configuration handling in Mageia package differs from upstream one on several
points:
- the automounts daemon configuration file is /etc/autofs/autofs.conf
- the autofs service configuration file is /etc/sysconfig/autofs
Upgrade
-------
Map files have been moved from /etc to /etc/autofs. Upgrade
procedure should handle the change automatically."

 $ ls /etc/autofs/
autofs       autofs_ldap_auth.conf  auto.misc  auto.smb*
autofs.conf  auto.master            auto.net

Re-assigning globally because no registered maintainer now; CC DavidW as most recent committer.

Assignee: shlomif => pkg-bugs
CC: (none) => luigiwalser

Fixed in SVN.  It's just a commented example, so that's good enough.

Resolution: (none) => FIXED
Whiteboard: OK MGA6TOO => (none)
Status: NEW => RESOLVED