Re: comment #15
> autopkgtest for dotnet6/6.0.128-0ubuntu1~22.04.1: amd64: Regression ♻ ,
> arm64: Regression ♻
> autopkgtest for linux-hwe-5.19/5.19.0-50.50: amd64: Pass, arm64: Regression ♻
> , ...
> autopkgtest for linux-hwe-6.5/6.5.0-27.28~22.04.1: arm64: Regression ♻ , ...
dotnet6 amd64
apparently unrelated; rerunning without core-utils as trigger:
- rerun with trigger on dotnet6 (from proposed)
- rerun with trigger on glibc (last passing)
dotnet6 jammy/arm64
likewise
linux-hwe-5.19/arm64
timedout several times
rerun
linux-hwe-6.5/arm64
timeout several times
rerun
linux-gcp-5.19 and -6.2 already cleared due to reruns.
Proposed {linux,linux-*}/{arm64,armhf} to long_tests [1] per [2].
[1]
https://code.launchpad.net/~mfo/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/462861
[2] https://wiki.ubuntu.com/ProposedMigration#autopkgtests
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2033892
Title:
ls -l triggers mount of autofs shares when --ghost option is present
or browse_mode is enabled
Status in coreutils package in Ubuntu:
Fix Released
Status in coreutils source package in Jammy:
Fix Committed
Status in coreutils package in Fedora:
Fix Released
Bug description:
[Impact]
Issuing a 'ls -l' or a 'stat' on an autofs share when you have set
--ghost in the auto.master file, or browse_mode=yes in autofs.conf
will lead to the shares being mounted, when they didn't previously.
Disks / shares may not be present and the mounts may fail, leading to
errors in your output.
This is a behaviour change in autofs 8.32, which occurred in the
transition to using statx() instead of stat()/lstat() in previous
releases.
There doesn't seem to be any workarounds, apart from not running a 'ls
-l' in your autofs share directory.
[Testcase]
Start two Jammy VMs. One will be a NFS server, the other, the client.
NFS server:
Server VM:
$ sudo hostnamectl set-hostname jammy-nfs-server
$ sudo apt update && sudo apt upgrade -y
$ sudo apt install nfs-kernel-server
$ sudo mkdir /export
$ sudo mkdir /export/users
$ sudo vi /etc/exports # add the following lines:
/export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync)
/export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
$ sudo systemctl restart nfs-server.service
AutoFS Client:
$ sudo apt update
$ sudo apt install autofs
$ sudo vim /etc/autofs.conf
browse_mode = yes
$ sudo mkdir /mnt2
$ sudo vim /etc/auto.master
/mnt2 /etc/auto.indirect
$ sudo vim /etc/auto.indirect
export 192.168.122.18:/export
export-missing 192.168.122.18:/export-missing
$ sudo reboot
$ cd /mnt2
$ ls -l
ls: cannot access 'export-missing': No such file or directory
total 4
drwxr-xr-x 3 root root 4096 Feb 12 21:48 export
d????????? ? ? ? ? ? export-missing
$ mount -l | grep /mnt2
/etc/auto.indirect on /mnt2 type autofs
(rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
192.168.122.18:/export on /mnt2/export type nfs
(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)
We see the mount for export occurred, and export-missing was
attempted, but it was either bogus or the disk was not present,
leading to a "No such file or directory" error.
There are test packages available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test
If you install them, this is what should occur:
$ ls -l
total 0
drwxr-xr-x 2 root root 0 Feb 12 22:01 export
drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing
$ mount -l | grep /mnt2
/etc/auto.indirect on /mnt2 type autofs
(rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346)
No mounts happen, and no errors either.
[Where problems could occur]
We are changing the behaviour of core utilities, ls and stat, such
that they no longer attempt to mount autofs shares when --ghost option
is present or browse_mode is enabled.
This is the intended behaviour in the first place, and has been this
way for at least a decade prior, and was changed to return to this
behaviour shortly after the release of coreutils that introduced
statx() that caused automounts to occur.
It is unlikely any system administrators are relying on the behaviour
found in jammy in any scripts or day to day operations that would be
adversely affected by the change. The worst case scenario is that a
user doing an 'ls -l' on an unmounted disk finds the mount doesn't
automatically occur, and they have to attach the disk and issue the
mount themselves.
If a regression were to occur, it would be limited to the ls and stat
commands, specifically when listing directories linked to autofs
mountpoints.
[Other info]
The automount behaviour change was introduced upstream in version
8.32, with the introduction of the statx() call. This means only Jammy
is affected.
It was quickly reverted back to how it was originally in version 9.1,
which is already available in Mantic and onward.
The commits that solve the issue are:
commit 85c975df2c25bd799370b04bb294e568e001102f
From: Rohan Sable <rsa...@redhat.com>
Date: Mon, 7 Mar 2022 14:14:13 +0000
Subject: ls: avoid triggering automounts
Link:
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2
commit 92cb8427c537f37edd43c5cef1909585201372ab
From: Pádraig Brady <p...@draigbrady.com>
Date: Mon, 7 Mar 2022 23:29:20 +0000
Subject: stat: only automount with --cached=never
Link:
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53
Upstream bugs:
https://bugs.gnu.org/54286
https://bugs.gnu.org/54287
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
