* stat -L triggering mount (behavior change starting with 2.6.38-rc1)
@ 2011-03-28 22:53 Leonardo Chiquitto
2011-04-01 4:27 ` Ian Kent
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Leonardo Chiquitto @ 2011-03-28 22:53 UTC (permalink / raw)
To: autofs
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
Hello,
After the update to 2.6.38, I noticed that AutoFS started to mount volumes
at times it normally wouldn't. More specifically, "ls -la" inside an AutoFS
mount point will trigger the mount of all available maps.
This can be reproduced with a simple indirect mount setup:
# cat /etc/auto.master
/data /etc/auto.data
# cat /etc/auto.data
isos -fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos
# egrep '(autofs|nfs4)' /proc/mounts
/etc/auto.data /data autofs rw,relatime,fd=7,pgrp=4300,timeout=600,minproto=5,\
maxproto=5,indirect 0 0
# stat -L /data/isos > /dev/null
# egrep '(autofs|nfs4)' /proc/mounts
/etc/auto.data /data autofs rw,relatime,fd=7,pgrp=4300,timeout=600,minproto=5,\
maxproto=5,indirect 0 0
libre:/isos /data/isos nfs4 ro,nosuid,relatime,vers=4,(.. more mount
options ..) 0 0
Bisecting the changes between 2.6.37 and 2.6.38, I found that 2.6.38-rc1
exhibits the new behavior already. I went as near 2.6.37 as I could and verified
that commit b650c858c2 (autofs4: Merge the remaining dentry ops tables) also
shows the new behavior. I tried to bisect the remaining ~18 commits
but everything
I tested/built ended up unbootable.
I also tested mainline and verified that the problem is still there.
Although everything points to a kernel change, I'm attaching debug logs from
the automounter, just in case it's useful to someone.
Thanks,
Leonardo
[-- Attachment #2: messages-n63.txt --]
[-- Type: text/plain, Size: 3671 bytes --]
=== STARTUP
Mar 28 19:30:43 n63 automount[4389]: Starting automounter version 5.0.5, master map auto.master
Mar 28 19:30:43 n63 automount[4389]: using kernel protocol version 5.02
Mar 28 19:30:43 n63 automount[4389]: lookup_nss_read_master: reading master files auto.master
Mar 28 19:30:43 n63 automount[4389]: parse_init: parse(sun): init gathered global options: (null)
Mar 28 19:30:43 n63 automount[4389]: lookup_read_master: lookup(file): read entry /data
Mar 28 19:30:43 n63 automount[4389]: master_do_mount: mounting /data
Mar 28 19:30:43 n63 automount[4389]: automount_path_to_fifo: fifo name /var/run/autofs.fifo-data
Mar 28 19:30:43 n63 automount[4389]: lookup_nss_read_map: reading map file /etc/auto.data
Mar 28 19:30:43 n63 automount[4389]: parse_init: parse(sun): init gathered global options: (null)
Mar 28 19:30:43 n63 automount[4389]: mounted indirect on /data with timeout 600, freq 150 seconds
Mar 28 19:30:43 n63 automount[4389]: st_ready: st_ready(): state = 0 path /data
Mar 28 19:30:43 n63 automount[4389]: ghosting enabled
=== COMMAND: stat -L /data/isos
Mar 28 19:31:18 n63 automount[4389]: handle_packet: type = 3
Mar 28 19:31:18 n63 automount[4389]: handle_packet_missing_indirect: token 1, name isos, request pid 4398
Mar 28 19:31:18 n63 automount[4389]: attempting to mount entry /data/isos
Mar 28 19:31:18 n63 automount[4389]: lookup_mount: lookup(file): looking up isos
Mar 28 19:31:18 n63 automount[4389]: lookup_mount: lookup(file): isos -> -fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos
Mar 28 19:31:18 n63 automount[4389]: parse_mount: parse(sun): expanded entry: -fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos
Mar 28 19:31:18 n63 automount[4389]: parse_mount: parse(sun): gathered options: fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid
Mar 28 19:31:18 n63 automount[4389]: parse_mount: parse(sun): dequote("libre:/isos") -> libre:/isos
Mar 28 19:31:18 n63 automount[4389]: parse_mount: parse(sun): core of entry: options=fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid, loc=libre:/isos
Mar 28 19:31:18 n63 automount[4389]: sun_mount: parse(sun): mounting root /data, mountpoint isos, what libre:/isos, fstype nfs4, options ro,rsize=8192,wsize=8192,intr,nolock,nosuid
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): root=/data name=isos what=libre:/isos, fstype=nfs4, options=ro,rsize=8192,wsize=8192,intr,nolock,nosuid
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): nfs options="ro,rsize=8192,wsize=8192,intr,nolock,nosuid", nosymlink=0, ro=1
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): calling mkdir_path /data/isos
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): calling mount -t nfs4 -s -o ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos /data/isos
Mar 28 19:31:18 n63 request-key: Cannot find command to construct key 33463049
Mar 28 19:31:18 n63 request-key: Cannot find command to construct key 481955300
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): mounted libre:/isos on /data/isos
Mar 28 19:31:18 n63 automount[4389]: dev_ioctl_send_ready: token = 1
Mar 28 19:31:18 n63 automount[4389]: mounted /data/isos
Mar 28 19:31:18 n63 automount[4389]: st_readmap: state 1 path /data
Mar 28 19:31:18 n63 automount[4389]: re-reading map for /data
Mar 28 19:31:18 n63 automount[4389]: lookup_nss_read_map: reading map file /etc/auto.data
Mar 28 19:31:18 n63 automount[4389]: parse_init: parse(sun): init gathered global options: (null)
Mar 28 19:31:18 n63 automount[4389]: st_ready: st_ready(): state = 4 path /data
Mar 28 19:31:21 n63 dhclient: XMT: Solicit on eth0, interval 113240ms.
[-- Attachment #3: Type: text/plain, Size: 140 bytes --]
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
^ permalink raw reply [flat|nested] 14+ messages in thread
* stat -L triggering mount (behavior change starting with 2.6.38-rc1)
@ 2011-03-30 16:19 Leonardo Chiquitto
0 siblings, 0 replies; 14+ messages in thread
From: Leonardo Chiquitto @ 2011-03-30 16:19 UTC (permalink / raw)
To: autofs
[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]
(note: I'm resending this because it apparently didn't reach the mailing list,
sorry if someone is getting it twice)
Hello,
After the update to 2.6.38, I noticed that AutoFS started to mount volumes
at times it normally wouldn't. More specifically, "ls -la" inside an AutoFS
mount point will trigger the mount of all available maps.
This can be reproduced with a simple indirect mount setup:
# cat /etc/auto.master
/data /etc/auto.data
# cat /etc/auto.data
isos -fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos
# egrep '(autofs|nfs4)' /proc/mounts
/etc/auto.data /data autofs rw,relatime,fd=7,pgrp=4300,timeout=600,minproto=5,\
maxproto=5,indirect 0 0
# stat -L /data/isos > /dev/null
# egrep '(autofs|nfs4)' /proc/mounts
/etc/auto.data /data autofs rw,relatime,fd=7,pgrp=4300,timeout=600,minproto=5,\
maxproto=5,indirect 0 0
libre:/isos /data/isos nfs4 ro,nosuid,relatime,vers=4,(.. more mount\
options ..) 0 0
Bisecting the changes between 2.6.37 and 2.6.38, I found that 2.6.38-rc1
exhibits the new behavior already. I went as near 2.6.37 as I could and verified
that commit b650c858c2 (autofs4: Merge the remaining dentry ops tables) also
shows the new behavior. I tried to bisect the remaining ~18 commits
but everything I tested/built ended up unbootable.
I also tested mainline and verified that the problem is still there.
Although everything points to a kernel change, I'm attaching debug logs from
the automounter, just in case it's useful to someone.
Thanks,
Leonardo
[-- Attachment #2: messages-n63.txt --]
[-- Type: text/plain, Size: 3671 bytes --]
=== STARTUP
Mar 28 19:30:43 n63 automount[4389]: Starting automounter version 5.0.5, master map auto.master
Mar 28 19:30:43 n63 automount[4389]: using kernel protocol version 5.02
Mar 28 19:30:43 n63 automount[4389]: lookup_nss_read_master: reading master files auto.master
Mar 28 19:30:43 n63 automount[4389]: parse_init: parse(sun): init gathered global options: (null)
Mar 28 19:30:43 n63 automount[4389]: lookup_read_master: lookup(file): read entry /data
Mar 28 19:30:43 n63 automount[4389]: master_do_mount: mounting /data
Mar 28 19:30:43 n63 automount[4389]: automount_path_to_fifo: fifo name /var/run/autofs.fifo-data
Mar 28 19:30:43 n63 automount[4389]: lookup_nss_read_map: reading map file /etc/auto.data
Mar 28 19:30:43 n63 automount[4389]: parse_init: parse(sun): init gathered global options: (null)
Mar 28 19:30:43 n63 automount[4389]: mounted indirect on /data with timeout 600, freq 150 seconds
Mar 28 19:30:43 n63 automount[4389]: st_ready: st_ready(): state = 0 path /data
Mar 28 19:30:43 n63 automount[4389]: ghosting enabled
=== COMMAND: stat -L /data/isos
Mar 28 19:31:18 n63 automount[4389]: handle_packet: type = 3
Mar 28 19:31:18 n63 automount[4389]: handle_packet_missing_indirect: token 1, name isos, request pid 4398
Mar 28 19:31:18 n63 automount[4389]: attempting to mount entry /data/isos
Mar 28 19:31:18 n63 automount[4389]: lookup_mount: lookup(file): looking up isos
Mar 28 19:31:18 n63 automount[4389]: lookup_mount: lookup(file): isos -> -fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos
Mar 28 19:31:18 n63 automount[4389]: parse_mount: parse(sun): expanded entry: -fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos
Mar 28 19:31:18 n63 automount[4389]: parse_mount: parse(sun): gathered options: fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid
Mar 28 19:31:18 n63 automount[4389]: parse_mount: parse(sun): dequote("libre:/isos") -> libre:/isos
Mar 28 19:31:18 n63 automount[4389]: parse_mount: parse(sun): core of entry: options=fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid, loc=libre:/isos
Mar 28 19:31:18 n63 automount[4389]: sun_mount: parse(sun): mounting root /data, mountpoint isos, what libre:/isos, fstype nfs4, options ro,rsize=8192,wsize=8192,intr,nolock,nosuid
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): root=/data name=isos what=libre:/isos, fstype=nfs4, options=ro,rsize=8192,wsize=8192,intr,nolock,nosuid
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): nfs options="ro,rsize=8192,wsize=8192,intr,nolock,nosuid", nosymlink=0, ro=1
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): calling mkdir_path /data/isos
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): calling mount -t nfs4 -s -o ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos /data/isos
Mar 28 19:31:18 n63 request-key: Cannot find command to construct key 33463049
Mar 28 19:31:18 n63 request-key: Cannot find command to construct key 481955300
Mar 28 19:31:18 n63 automount[4389]: mount_mount: mount(nfs): mounted libre:/isos on /data/isos
Mar 28 19:31:18 n63 automount[4389]: dev_ioctl_send_ready: token = 1
Mar 28 19:31:18 n63 automount[4389]: mounted /data/isos
Mar 28 19:31:18 n63 automount[4389]: st_readmap: state 1 path /data
Mar 28 19:31:18 n63 automount[4389]: re-reading map for /data
Mar 28 19:31:18 n63 automount[4389]: lookup_nss_read_map: reading map file /etc/auto.data
Mar 28 19:31:18 n63 automount[4389]: parse_init: parse(sun): init gathered global options: (null)
Mar 28 19:31:18 n63 automount[4389]: st_ready: st_ready(): state = 4 path /data
Mar 28 19:31:21 n63 dhclient: XMT: Solicit on eth0, interval 113240ms.
[-- Attachment #3: Type: text/plain, Size: 140 bytes --]
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2011-03-28 22:53 stat -L triggering mount (behavior change starting with 2.6.38-rc1) Leonardo Chiquitto
@ 2011-04-01 4:27 ` Ian Kent
2011-04-01 4:55 ` Ian Kent
2011-04-01 4:38 ` Ian Kent
` (2 subsequent siblings)
3 siblings, 1 reply; 14+ messages in thread
From: Ian Kent @ 2011-04-01 4:27 UTC (permalink / raw)
To: Leonardo Chiquitto; +Cc: autofs, David Howells
On Mon, 2011-03-28 at 19:53 -0300, Leonardo Chiquitto wrote:
> Hello,
>
> After the update to 2.6.38, I noticed that AutoFS started to mount volumes
> at times it normally wouldn't. More specifically, "ls -la" inside an AutoFS
> mount point will trigger the mount of all available maps.
>
> This can be reproduced with a simple indirect mount setup:
>
> # cat /etc/auto.master
> /data /etc/auto.data
>
> # cat /etc/auto.data
> isos -fstype=nfs4,ro,rsize=8192,wsize=8192,intr,nolock,nosuid libre:/isos
>
> # egrep '(autofs|nfs4)' /proc/mounts
> /etc/auto.data /data autofs rw,relatime,fd=7,pgrp=4300,timeout=600,minproto=5,\
> maxproto=5,indirect 0 0
>
> # stat -L /data/isos > /dev/null
How about an strace of this please?
>
> # egrep '(autofs|nfs4)' /proc/mounts
> /etc/auto.data /data autofs rw,relatime,fd=7,pgrp=4300,timeout=600,minproto=5,\
> maxproto=5,indirect 0 0
> libre:/isos /data/isos nfs4 ro,nosuid,relatime,vers=4,(.. more mount
> options ..) 0 0
>
> Bisecting the changes between 2.6.37 and 2.6.38, I found that 2.6.38-rc1
> exhibits the new behavior already. I went as near 2.6.37 as I could and verified
> that commit b650c858c2 (autofs4: Merge the remaining dentry ops tables) also
> shows the new behavior. I tried to bisect the remaining ~18 commits
> but everything
> I tested/built ended up unbootable.
>
> I also tested mainline and verified that the problem is still there.
There where two significant patch series merged in 2.6.38 which were to
similar parts of the VFS. One was the vfs-scale series and the other was
the vfs-automount series. So 2.6.38 had significant autofs changes.
I think the mount storm your seeing would be due to this check not
catching lstat(2) calls, but AFAICS it should catch this case:
if (!(flags & LOOKUP_FOLLOW) &&
!(flags & (LOOKUP_CONTINUE | LOOKUP_DIRECTORY |
LOOKUP_OPEN | LOOKUP_CREATE)))
return -EISDIR;
What do you think David?
Ian
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2011-03-28 22:53 stat -L triggering mount (behavior change starting with 2.6.38-rc1) Leonardo Chiquitto
2011-04-01 4:27 ` Ian Kent
@ 2011-04-01 4:38 ` Ian Kent
2011-04-01 12:13 ` Leonardo Chiquitto
2011-04-01 9:19 ` David Howells
2013-03-26 12:56 ` toto
3 siblings, 1 reply; 14+ messages in thread
From: Ian Kent @ 2011-04-01 4:38 UTC (permalink / raw)
To: Leonardo Chiquitto; +Cc: autofs, David Howells
On Mon, 2011-03-28 at 19:53 -0300, Leonardo Chiquitto wrote:
>
> Bisecting the changes between 2.6.37 and 2.6.38, I found that 2.6.38-rc1
> exhibits the new behavior already. I went as near 2.6.37 as I could and verified
> that commit b650c858c2 (autofs4: Merge the remaining dentry ops tables) also
> shows the new behavior. I tried to bisect the remaining ~18 commits
> but everything
> I tested/built ended up unbootable.
>
> I also tested mainline and verified that the problem is still there.
I suspect it will but does it also happen with 2.6.39-rc1?
Ian
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2011-04-01 4:27 ` Ian Kent
@ 2011-04-01 4:55 ` Ian Kent
0 siblings, 0 replies; 14+ messages in thread
From: Ian Kent @ 2011-04-01 4:55 UTC (permalink / raw)
To: Leonardo Chiquitto; +Cc: autofs, David Howells
On Fri, 2011-04-01 at 12:27 +0800, Ian Kent wrote:
> On Mon, 2011-03-28 at 19:53 -0300, Leonardo Chiquitto wrote:
>
> There where two significant patch series merged in 2.6.38 which were to
> similar parts of the VFS. One was the vfs-scale series and the other was
> the vfs-automount series. So 2.6.38 had significant autofs changes.
>
> I think the mount storm your seeing would be due to this check not
> catching lstat(2) calls, but AFAICS it should catch this case:
>
Oh, hang on, we have this comment in the VFS code!
/* We want to mount if someone is trying to open/create a file of any
* type under the mountpoint, wants to traverse through the mountpoint
* or wants to open the mounted directory.
*
* We don't want to mount if someone's just doing a stat and they've
* set AT_SYMLINK_NOFOLLOW - unless they're stat'ing a directory and
* appended a '/' to the name.
*/
> if (!(flags & LOOKUP_FOLLOW) &&
> !(flags & (LOOKUP_CONTINUE | LOOKUP_DIRECTORY |
> LOOKUP_OPEN | LOOKUP_CREATE)))
> return -EISDIR;
>
But "stat -L" says de-reference (a stat(2) call, not an lstat(2) call)
the symlink so AT_SYMLINK_NOFOLLOW is not set and consequently
LOOKUP_FOLLOW will be set. Since automounting modules no longer see the
lookup flags autofs doesn't know about this.
I missed this case, oops!
I'm not even sure what we can do about it either since this code is
shared by other file systems than autofs that don't need to tell lies
when stat()ing a directory to prevent mount storms.
mmm ...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2011-03-28 22:53 stat -L triggering mount (behavior change starting with 2.6.38-rc1) Leonardo Chiquitto
2011-04-01 4:27 ` Ian Kent
2011-04-01 4:38 ` Ian Kent
@ 2011-04-01 9:19 ` David Howells
2011-04-01 12:20 ` Leonardo Chiquitto
2011-04-01 14:27 ` David Howells
2013-03-26 12:56 ` toto
3 siblings, 2 replies; 14+ messages in thread
From: David Howells @ 2011-04-01 9:19 UTC (permalink / raw)
To: Leonardo Chiquitto; +Cc: dhowells, autofs, Ian Kent
Hi Leonardo,
Could you send us a strace of "ls -l" on your autofs directory?
I think the problem is not lstat() calls, but rather getxattr() calls.
Thanks,
David
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2011-04-01 4:38 ` Ian Kent
@ 2011-04-01 12:13 ` Leonardo Chiquitto
0 siblings, 0 replies; 14+ messages in thread
From: Leonardo Chiquitto @ 2011-04-01 12:13 UTC (permalink / raw)
To: Ian Kent; +Cc: autofs, David Howells
On Fri, Apr 1, 2011 at 1:38 AM, Ian Kent <raven@themaw.net> wrote:
> On Mon, 2011-03-28 at 19:53 -0300, Leonardo Chiquitto wrote:
>>
>> Bisecting the changes between 2.6.37 and 2.6.38, I found that 2.6.38-rc1
>> exhibits the new behavior already. I went as near 2.6.37 as I could and verified
>> that commit b650c858c2 (autofs4: Merge the remaining dentry ops tables) also
>> shows the new behavior. I tried to bisect the remaining ~18 commits
>> but everything
>> I tested/built ended up unbootable.
>>
>> I also tested mainline and verified that the problem is still there.
>
> I suspect it will but does it also happen with 2.6.39-rc1?
Yes, still reproducible with 2.6.39-rc1-vanilla+ (commit ecb78ab6f3).
Leonardo
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2011-04-01 9:19 ` David Howells
@ 2011-04-01 12:20 ` Leonardo Chiquitto
2011-04-01 14:27 ` David Howells
1 sibling, 0 replies; 14+ messages in thread
From: Leonardo Chiquitto @ 2011-04-01 12:20 UTC (permalink / raw)
To: David Howells; +Cc: autofs, Ian Kent
[-- Attachment #1: Type: text/plain, Size: 328 bytes --]
On Fri, Apr 1, 2011 at 6:19 AM, David Howells <dhowells@redhat.com> wrote:
>
> Hi Leonardo,
>
> Could you send us a strace of "ls -l" on your autofs directory?
>
> I think the problem is not lstat() calls, but rather getxattr() calls.
Attached. This is from a machine running 2.6.39-rc1-vanilla+ (commit
ecb78ab6f3).
Leonardo
[-- Attachment #2: strace-ls-autofs.txt --]
[-- Type: text/plain, Size: 17837 bytes --]
execve("/bin/ls", ["ls", "-l", "/data"], [/* 54 vars */]) = 0
brk(0) = 0x61c000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f96c7fc1000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=95548, ...}) = 0
mmap(NULL, 95548, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f96c7fa9000
close(3) = 0
open("/lib64/libselinux.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220^\0\0\0\0\0\0@\0\0\0\0\0\0\0\260\325\1\0\0\0\0\0\0\0\0\0@\0008\0\10\0@\0\36\0\35\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\224\300\1\0\0\0\0\0\224\300\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\315\1\0\0\0\0\0X\315!\0\0\0\0\0X\315!\0\0\0\0\0,\7\0\0\0\0\0\0\270\31\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\270\315\1\0\0\0\0\0\270\315!\0\0\0\0\0\270\315!\0\0\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0\2\0\0\0\0\0\0\0\2\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=122160, ...}) = 0
mmap(NULL, 2221840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f96c7b86000
fadvise64(3, 0, 2221840, POSIX_FADV_WILLNEED) = 0
mprotect(0x7f96c7ba3000, 2093056, PROT_NONE) = 0
mmap(0x7f96c7da2000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0x7f96c7da2000
mmap(0x7f96c7da4000, 1808, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f96c7da4000
close(3) = 0
open("/lib64/librt.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\"\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\204\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0%\0\"\0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0@_\0\0\0\0\0\0@_\0\0\0\0\0\0@_\0\0\0\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0,r\0\0\0\0\0\0,r\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0x}\0\0\0\0\0\0x} \0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=47329, ...}) = 0
mmap(NULL, 2133008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f96c797d000
fadvise64(3, 0, 2133008, POSIX_FADV_WILLNEED) = 0
mprotect(0x7f96c7985000, 2093056, PROT_NONE) = 0
mmap(0x7f96c7b84000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f96c7b84000
close(3) = 0
open("/lib64/libcap.so.2", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\25\0\0\0\0\0\0@\0\0\0\0\0\0\0(C\0\0\0\0\0\0\0\0\0\0@\0008\0\7\0@\0\34\0\33\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3146\0\0\0\0\0\0\3146\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\0>\0\0\0\0\0\0\0> \0\0\0\0\0\0> \0\0\0\0\0\20\4\0\0\0\0\0\0 \4\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0(>\0\0\0\0\0\0(> \0\0\0\0\0(> \0\0\0\0\0\240\1\0\0\0\0\0\0\240\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\310\1\0\0\0\0\0\0\310\1\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=18984, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f96c7fa8000
mmap(NULL, 2114080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f96c7778000
fadvise64(3, 0, 2114080, POSIX_FADV_WILLNEED) = 0
mprotect(0x7f96c777c000, 2093056, PROT_NONE) = 0
mmap(0x7f96c797b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f96c797b000
close(3) = 0
open("/lib64/libacl.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p \0\0\0\0\0\0@\0\0\0\0\0\0\0`\203\0\0\0\0\0\0\0\0\0\0@\0008\0\7\0@\0\35\0\34\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\254o\0\0\0\0\0\0\254o\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\300}\0\0\0\0\0\0\300} \0\0\0\0\0\300} \0\0\0\0\0x\4\0\0\0\0\0\0\260\4\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\350}\0\0\0\0\0\0\350} \0\0\0\0\0\350} \0\0\0\0\0\320\1\0\0\0\0\0\0\320\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\310\1\0\0\0\0\0\0\310\1\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=35488, ...}) = 0
mmap(NULL, 2130544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f96c756f000
fadvise64(3, 0, 2130544, POSIX_FADV_WILLNEED) = 0
mprotect(0x7f96c7576000, 2097152, PROT_NONE) = 0
mmap(0x7f96c7776000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f96c7776000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\355\1\0\0\0\0\0@\0\0\0\0\0\0\0\0\214\26\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0K\0H\0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0000\2\0\0\0\0\0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0@8\23\0\0\0\0\0@8\23\0\0\0\0\0@8\23\0\0\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3142\26\0\0\0\0\0\3142\26\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0P7\26\0\0\0\0\0P76\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1725484, ...}) = 0
mmap(NULL, 3591144, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f96c7202000
fadvise64(3, 0, 3591144, POSIX_FADV_WILLNEED) = 0
mprotect(0x7f96c7366000, 2093056, PROT_NONE) = 0
mmap(0x7f96c7565000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x163000) = 0x7f96c7565000
mmap(0x7f96c756a000, 19432, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f96c756a000
close(3) = 0
open("/lib64/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\r\0\0\0\0\0\0@\0\0\0\0\0\0\0\3501\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0 \0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\31\0\0\0\0\0\0\240\31\0\0\0\0\0\0\240\31\0\0\0\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0P\37\0\0\0\0\0\0P\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h-\0\0\0\0\0\0h- \0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=19149, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f96c7fa7000
mmap(NULL, 2109704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f96c6ffe000
fadvise64(3, 0, 2109704, POSIX_FADV_WILLNEED) = 0
mprotect(0x7f96c7000000, 2097152, PROT_NONE) = 0
mmap(0x7f96c7200000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f96c7200000
close(3) = 0
open("/lib64/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 Z\0\0\0\0\0\0@\0\0\0\0\0\0\0\10\205\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0$\0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\0\34\1\0\0\0\0\0\0\34\1\0\0\0\0\0\0\34\1\0\0\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0@n\1\0\0\0\0\0@n\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\270{\1\0\0\0\0\0\270{!\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=135934, ...}) = 0
mmap(NULL, 2212736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f96c6de1000
fadvise64(3, 0, 2212736, POSIX_FADV_WILLNEED) = 0
mprotect(0x7f96c6df8000, 2097152, PROT_NONE) = 0
mmap(0x7f96c6ff8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f96c6ff8000
mmap(0x7f96c6ffa000, 13184, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f96c6ffa000
close(3) = 0
open("/lib64/libattr.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\24\0\0\0\0\0\0@\0\0\0\0\0\0\0pB\0\0\0\0\0\0\0\0\0\0@\0008\0\7\0@\0\35\0\34\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0$=\0\0\0\0\0\0$=\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340=\0\0\0\0\0\0\340= \0\0\0\0\0\340= \0\0\0\0\0h\3\0\0\0\0\0\0\200\3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\10>\0\0\0\0\0\0\10> \0\0\0\0\0\10> \0\0\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\310\1\0\0\0\0\0\0\310\1\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=18864, ...}) = 0
mmap(NULL, 2113888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f96c6bdc000
fadvise64(3, 0, 2113888, POSIX_FADV_WILLNEED) = 0
mprotect(0x7f96c6be0000, 2093056, PROT_NONE) = 0
mmap(0x7f96c6ddf000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f96c6ddf000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f96c7fa6000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f96c7fa4000
arch_prctl(ARCH_SET_FS, 0x7f96c7fa47a0) = 0
mprotect(0x7f96c6ddf000, 4096, PROT_READ) = 0
mprotect(0x7f96c6ff8000, 4096, PROT_READ) = 0
mprotect(0x7f96c7200000, 4096, PROT_READ) = 0
mprotect(0x7f96c7565000, 16384, PROT_READ) = 0
mprotect(0x7f96c7776000, 4096, PROT_READ) = 0
mprotect(0x7f96c797b000, 4096, PROT_READ) = 0
mprotect(0x7f96c7b84000, 4096, PROT_READ) = 0
mprotect(0x7f96c7da2000, 4096, PROT_READ) = 0
mprotect(0x619000, 4096, PROT_READ) = 0
mprotect(0x7f96c7fc2000, 4096, PROT_READ) = 0
munmap(0x7f96c7fa9000, 95548) = 0
set_tid_address(0x7f96c7fa4a70) = 4687
set_robust_list(0x7f96c7fa4a80, 0x18) = 0
futex(0x7fffa96a574c, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fffa96a574c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f96c7fa47a0) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x7f96c6de64a0, [], SA_RESTORER|SA_SIGINFO, 0x7f96c6df02d0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7f96c6de6530, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f96c6df02d0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
statfs("/selinux", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=2297542, f_bfree=1196179, f_bavail=1079469, f_files=584064, f_ffree=441884, f_fsid={1837879043, 553698574}, f_namelen=255, f_frsize=4096}) = 0
brk(0) = 0x61c000
brk(0x63d000) = 0x63d000
open("/proc/filesystems", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f96c7fc0000
read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tbdev\nnodev\tproc\nnodev\tcgroup\nnodev\tcpuset\nnodev\ttmpfs\nnodev\tdevtmpfs\nnodev\tdebugfs\nnodev\tsecurityfs\nnodev\tsockfs\nnodev\tpipefs\nnodev\tanon_inodefs\nnodev\trpc_pipefs\nnodev\tdevpts\n\text3\n\text2\n\text4\nnodev\tramfs\nnodev\thugetlbfs\n\tiso"..., 1024) = 321
read(3, "", 1024) = 0
close(3) = 0
munmap(0x7f96c7fc0000, 4096) = 0
open("/usr/lib/locale/locale-archive", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2512, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f96c7fc0000
read(3, "# Locale name alias data base.\n# Copyright (C) 1996-2001,2003,2007 Free Software Foundation, Inc.\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License as published by\n# the Free Sof"..., 4096) = 2512
read(3, "", 4096) = 0
close(3) = 0
munmap(0x7f96c7fc0000, 4096) = 0
open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=256324, ...}) = 0
mmap(NULL, 256324, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f96c7f65000
close(3) = 0
open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=26050, ...}) = 0
mmap(NULL, 26050, PROT_READ, MAP_SHARED, 3, 0) = 0x7f96c7fba000
close(3) = 0
futex(0x7f96c7569f60, FUTEX_WAKE_PRIVATE, 2147483647) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=37, ws_col=100, ws_xpixel=0, ws_ypixel=0}) = 0
lstat("/data", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lgetxattr("/data", "security.selinux", 0x622440, 255) = -1 EOPNOTSUPP (Operation not supported)
getxattr("/data", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
sendto(3, "\2\0\0\0\v\0\0\0\7\0\0\0passwd\0", 19, MSG_NOSIGNAL, NULL, 0) = 19
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(2)=[{"\t\314a\0\0\0\0", 7}, {"\310\366V\307\226\177\0\0", 8}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 0
close(3) = 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
sendto(3, "\2\0\0\0\1\0\0\0\2\0\0\0000\0", 14, MSG_NOSIGNAL, NULL, 0) = 14
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
read(3, "\2\0\0\0\1\0\0\0\5\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\6\0\0\0\n\0\0\0", 36) = 36
read(3, "root\0x\0root\0/root\0/bin/bash\0", 28) = 28
close(3) = 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
sendto(3, "\2\0\0\0\f\0\0\0\6\0\0\0group\0", 18, MSG_NOSIGNAL, NULL, 0) = 18
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(2)=[{"\3\0\0\0\31\0", 6}, {"\241\341\332\307\226\177\0\0", 8}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 0
close(3) = 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
sendto(3, "\2\0\0\0\3\0\0\0\2\0\0\0000\0", 14, MSG_NOSIGNAL, NULL, 0) = 14
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
read(3, "\2\0\0\0\1\0\0\0\5\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0", 24) = 24
read(3, "root\0x\0", 7) = 7
close(3) = 0
open("/data", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents64(3, /* 3 entries */, 32768) = 72
lstat("/data/isos", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lgetxattr("/data/isos", "security.selinux", 0x62ad60, 255) = -1 EOPNOTSUPP (Operation not supported)
getxattr("/data/isos", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
getdents64(3, /* 0 entries */, 32768) = 0
close(3) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(4, 1), ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f96c7fb9000
write(1, "total 0\n", 8) = 8
open("/etc/localtime", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2001, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=2001, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f96c7fb8000
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3\0\0\0\3\0\0\0\0\0\0\0\200\0\0\0\3\0\0\0\r\226\252r\264\270\17I\340\270\375@\240\271\36140\272\336t \3328\2560\332\353\3720\334\31\341\260\334\271Y \335\373\0250\336\233\336 \337\335\2320\340T3 \364Z\t0\365\5^ \366\300d0\367\16\36\240\370Q,0\370\307\305 \372\n\322\260\372\250\370\240\373\354\0060\374\213}\240\35\311\2160\36x\327\240\37\2405\260 3\317\240!\201i0\"\v\310\240#X\20\260#\342p %7\362\260%\324\307 '!\0170'\275\343\240)\0\3610)\224\213 *\352\r\260+k2\240,\300\2650-f\304 .\240\2270/F\246 0\200y01\35M\2402W \2603\6j 48T04\370\301 6 \03706\317h\2407\366\306\2608\270\205 "..., 4096) = 2001
lseek(3, -1280, SEEK_CUR) = 721
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3\0\0\0\3\0\0\0\0\0\0\0\202\0\0\0\3\0\0\0\r\377\377\377\377\226\252r\264\377\377\377\377\270\17I\340\377\377\377\377\270\375@\240\377\377\377\377\271\36140\377\377\377\377\272\336t \377\377\377\377\3328\2560\377\377\377\377\332\353\3720\377\377\377\377\334\31\341\260\377\377\377\377\334\271Y \377\377\377\377\335\373\0250\377\377\377\377\336\233\336 \377\377\377\377\337\335\2320\377\377\377\377\340T3 \377\377\377\377\364Z\t0\377\377\377\377\365\5^ \377\377\377\377\366\300d0\377\377\377\377\367\16\36\240\377\377\377\377\370Q,0\377\377\377\377\370\307\305 \377\377\377\377\372\n\322\260\377\377\377\377\372\250\370\240\377\377\377\377\373\354\0060\377\377\377\377\374\213}\240\0\0\0\0\35\311\2160\0\0\0\0\36x\327\240\0\0\0\0\37\2405\260\0\0\0\0"..., 4096) = 1280
close(3) = 0
munmap(0x7f96c7fb8000, 4096) = 0
write(1, "dr-xr-xr-x 2 root root 0 Apr 1 09:15 isos\n", 43) = 43
close(1) = 0
munmap(0x7f96c7fb9000, 4096) = 0
close(2) = 0
exit_group(0) = ?
[-- Attachment #3: Type: text/plain, Size: 140 bytes --]
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2011-04-01 9:19 ` David Howells
2011-04-01 12:20 ` Leonardo Chiquitto
@ 2011-04-01 14:27 ` David Howells
2011-08-03 14:16 ` Leonardo Chiquitto
1 sibling, 1 reply; 14+ messages in thread
From: David Howells @ 2011-04-01 14:27 UTC (permalink / raw)
To: Leonardo Chiquitto; +Cc: dhowells, autofs, Ian Kent
Leonardo Chiquitto <leonardo.lists@gmail.com> wrote:
> open("/data", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> getdents64(3, /* 3 entries */, 32768) = 72
> lstat("/data/isos", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
> lgetxattr("/data/isos", "security.selinux", 0x62ad60, 255) = -1 EOPNOTSUPP (Operation not supported)
> getxattr("/data/isos", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
> getdents64(3, /* 0 entries */, 32768) = 0
Yeah, I suspect the getxattr() is the problem. ls calls libacl to get the
Posix ACL of the target file, but that uses the getxattr() which asserts
LOOKUP_FOLLOW during the pathwalk, causing the automount unconditionally:-/
I'm discussing this with the coreutils and acl package maintainers to see if
we can fix it in userspace.
David
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2011-04-01 14:27 ` David Howells
@ 2011-08-03 14:16 ` Leonardo Chiquitto
0 siblings, 0 replies; 14+ messages in thread
From: Leonardo Chiquitto @ 2011-08-03 14:16 UTC (permalink / raw)
To: autofs; +Cc: David Howells, Ian Kent
On Fri, Apr 1, 2011 at 11:27 AM, David Howells <dhowells@redhat.com> wrote:
> Leonardo Chiquitto <leonardo.lists@gmail.com> wrote:
>
>> open("/data", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
>> fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
>> getdents64(3, /* 3 entries */, 32768) = 72
>> lstat("/data/isos", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
>> lgetxattr("/data/isos", "security.selinux", 0x62ad60, 255) = -1 EOPNOTSUPP (Operation not supported)
>> getxattr("/data/isos", "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
>> getdents64(3, /* 0 entries */, 32768) = 0
>
> Yeah, I suspect the getxattr() is the problem. ls calls libacl to get the
> Posix ACL of the target file, but that uses the getxattr() which asserts
> LOOKUP_FOLLOW during the pathwalk, causing the automount unconditionally:-/
>
> I'm discussing this with the coreutils and acl package maintainers to see if
> we can fix it in userspace.
Just for reference (in case someone's looking for a solution for this
in the archives),
the problem was fixed by the following changes:
1. libacl: Add acl_extended_file_nofollow()
http://git.savannah.gnu.org/gitweb/?p=acl.git;a=commitdiff;h=6bf5e24d48077db58b389e90558100fc121b8134
http://git.savannah.gnu.org/gitweb/?p=acl.git;a=commitdiff;h=ad4ca5aaee96e98b2e8e8a4351fa5e6c58d65216
http://git.savannah.gnu.org/gitweb/?p=acl.git;a=commitdiff;h=ebfeee80d4bffcbcbebcffb2f2d3db0427d01e2d
2. coreutils/gnulib: use acl_extended_file_nofollow if available
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=95f7c57ff4090a5dee062044d2c7b99879077808
Fixed packages are already available at least in the development versions of
openSUSE and Fedora.
Leonardo
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2011-03-28 22:53 stat -L triggering mount (behavior change starting with 2.6.38-rc1) Leonardo Chiquitto
` (2 preceding siblings ...)
2011-04-01 9:19 ` David Howells
@ 2013-03-26 12:56 ` toto
2013-03-26 20:41 ` Leonardo Chiquitto
3 siblings, 1 reply; 14+ messages in thread
From: toto @ 2013-03-26 12:56 UTC (permalink / raw)
To: autofs
Leonardo Chiquitto <leonardo.lists <at> gmail.com> writes:
>
> Hello,
>
> After the update to 2.6.38, I noticed that AutoFS started to mount volumes
> at times it normally wouldn't. More specifically, "ls -la" inside an AutoFS
> mount point will trigger the mount of all available maps.
__________
> autofs mailing list
> autofs <at> linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs
>
Hi,
When you are saying that "ls -la" should not trigger
the automounting of the volumes inside the directory,
what would be then the good command line to
trigger the mounting of volumes declared in auto.master ?
I am using Mac OS X 10.8.3 and by default,
the elements defined in automaster are mounted when
accessed by an application (like the Finder,
which is if you don't know the file manager of OS X), but how
then to trigger the silent mounting at startup
with a shell script ? Are there parameters to pass to "mount"
command to say "mount this folder
NOW as defined in auto master" ?
Thanking you in advance for your help.
Best regards,
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2013-03-26 12:56 ` toto
@ 2013-03-26 20:41 ` Leonardo Chiquitto
2013-03-27 0:13 ` Guillaume Apostoly
2013-03-27 4:06 ` Ian Kent
0 siblings, 2 replies; 14+ messages in thread
From: Leonardo Chiquitto @ 2013-03-26 20:41 UTC (permalink / raw)
To: toto; +Cc: autofs
On Tue, Mar 26, 2013 at 9:56 AM, toto <guillaume@apostoly.com> wrote:
> Leonardo Chiquitto <leonardo.lists <at> gmail.com> writes:
>
>>
>> Hello,
>>
>> After the update to 2.6.38, I noticed that AutoFS started to mount volumes
>> at times it normally wouldn't. More specifically, "ls -la" inside an AutoFS
>> mount point will trigger the mount of all available maps.
> __________
>> autofs mailing list
>> autofs <at> linux.kernel.org
>> http://linux.kernel.org/mailman/listinfo/autofs
>>
>
> Hi,
Hi,
> When you are saying that "ls -la" should not trigger
> the automounting of the volumes inside the directory,
> what would be then the good command line to
> trigger the mounting of volumes declared in auto.master ?
The problem that was discussed in this thread was about
accesses to a parent directory triggering mounts of volumes
in sub-directories. An example:
/nfs/volume1
/nfs/volume2
Here volume1 and volume2 are two automounted directories.
What was happening is that "ls -la /nfs" was triggering the
mounts of volume1 and volume2.
> I am using Mac OS X 10.8.3 and by default,
> the elements defined in automaster are mounted when
> accessed by an application (like the Finder,
> which is if you don't know the file manager of OS X), but how
> then to trigger the silent mounting at startup
> with a shell script ?
You just need to access the volume. Using the example above,
any of these should work:
$ stat /nfs/volume1/ # the slash at the end is important
$ cd /nfs/volume1
$ ls /nfs/volume1
> Are there parameters to pass to "mount"
> command to say "mount this folder
> NOW as defined in auto master" ?
No, not that I'm aware.
Thanks,
Leonardo
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2013-03-26 20:41 ` Leonardo Chiquitto
@ 2013-03-27 0:13 ` Guillaume Apostoly
2013-03-27 4:06 ` Ian Kent
1 sibling, 0 replies; 14+ messages in thread
From: Guillaume Apostoly @ 2013-03-27 0:13 UTC (permalink / raw)
To: Leonardo Chiquitto; +Cc: toto, autofs@vger.kernel.org
Thanks for your quick answer ! I already tried cd and ls but it does not work, I will try stat tomorrow, until now the automount trigger is only working when trying to access from a GUI. I will let you know of the result.
Envoyé de mon iPad
Le 26 mars 2013 à 21:41, Leonardo Chiquitto <leonardo.lists@gmail.com> a écrit :
> On Tue, Mar 26, 2013 at 9:56 AM, toto <guillaume@apostoly.com> wrote:
>> Leonardo Chiquitto <leonardo.lists <at> gmail.com> writes:
>>
>>>
>>> Hello,
>>>
>>> After the update to 2.6.38, I noticed that AutoFS started to mount volumes
>>> at times it normally wouldn't. More specifically, "ls -la" inside an AutoFS
>>> mount point will trigger the mount of all available maps.
>> __________
>>> autofs mailing list
>>> autofs <at> linux.kernel.org
>>> http://linux.kernel.org/mailman/listinfo/autofs
>>
>> Hi,
>
> Hi,
>
>> When you are saying that "ls -la" should not trigger
>> the automounting of the volumes inside the directory,
>> what would be then the good command line to
>> trigger the mounting of volumes declared in auto.master ?
>
> The problem that was discussed in this thread was about
> accesses to a parent directory triggering mounts of volumes
> in sub-directories. An example:
>
> /nfs/volume1
> /nfs/volume2
>
> Here volume1 and volume2 are two automounted directories.
> What was happening is that "ls -la /nfs" was triggering the
> mounts of volume1 and volume2.
>
>> I am using Mac OS X 10.8.3 and by default,
>> the elements defined in automaster are mounted when
>> accessed by an application (like the Finder,
>> which is if you don't know the file manager of OS X), but how
>> then to trigger the silent mounting at startup
>> with a shell script ?
>
> You just need to access the volume. Using the example above,
> any of these should work:
>
> $ stat /nfs/volume1/ # the slash at the end is important
> $ cd /nfs/volume1
> $ ls /nfs/volume1
>
>> Are there parameters to pass to "mount"
>> command to say "mount this folder
>> NOW as defined in auto master" ?
>
> No, not that I'm aware.
>
> Thanks,
> Leonardo
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: stat -L triggering mount (behavior change starting with 2.6.38-rc1)
2013-03-26 20:41 ` Leonardo Chiquitto
2013-03-27 0:13 ` Guillaume Apostoly
@ 2013-03-27 4:06 ` Ian Kent
1 sibling, 0 replies; 14+ messages in thread
From: Ian Kent @ 2013-03-27 4:06 UTC (permalink / raw)
To: Leonardo Chiquitto; +Cc: toto, autofs
On Tue, 2013-03-26 at 17:41 -0300, Leonardo Chiquitto wrote:
> On Tue, Mar 26, 2013 at 9:56 AM, toto <guillaume@apostoly.com> wrote:
> > Leonardo Chiquitto <leonardo.lists <at> gmail.com> writes:
> >
> >>
> >> Hello,
> >>
> >> After the update to 2.6.38, I noticed that AutoFS started to mount volumes
> >> at times it normally wouldn't. More specifically, "ls -la" inside an AutoFS
> >> mount point will trigger the mount of all available maps.
> > __________
> >> autofs mailing list
> >> autofs <at> linux.kernel.org
> >> http://linux.kernel.org/mailman/listinfo/autofs
> >>
> >
> > Hi,
>
> Hi,
>
> > When you are saying that "ls -la" should not trigger
> > the automounting of the volumes inside the directory,
> > what would be then the good command line to
> > trigger the mounting of volumes declared in auto.master ?
>
> The problem that was discussed in this thread was about
> accesses to a parent directory triggering mounts of volumes
> in sub-directories. An example:
>
> /nfs/volume1
> /nfs/volume2
>
> Here volume1 and volume2 are two automounted directories.
> What was happening is that "ls -la /nfs" was triggering the
> mounts of volume1 and volume2.
That's right, hence the problem could only occur with indirect mount
maps that used the "browse" option. When the browse option isn't used
the mount point directories don't get pre-created so the mount occurs
with access by create type usage (create being a vfs lookup, not
necessarily a create type system call).
>
> > I am using Mac OS X 10.8.3 and by default,
> > the elements defined in automaster are mounted when
> > accessed by an application (like the Finder,
> > which is if you don't know the file manager of OS X), but how
> > then to trigger the silent mounting at startup
> > with a shell script ?
>
> You just need to access the volume. Using the example above,
> any of these should work:
>
> $ stat /nfs/volume1/ # the slash at the end is important
> $ cd /nfs/volume1
> $ ls /nfs/volume1
Yes, the trailing "/" causes the vfs to treat the lookup as a directory
lookup which will cause the automounter to be sent a mount request for
the directory. It should only be needed when the browse option is used
with an indirect mount map.
There were some transitional kernel revisions from 2.6.38, resulting
from the vfs-automount infrastructure introduction (a large change),
where the behavior would cause excessive mounting, AFAICR it was mostly
due to inconsistent system call usage by user space utilities.
>
> > Are there parameters to pass to "mount"
> > command to say "mount this folder
> > NOW as defined in auto master" ?
Not sure what that means, it sounds like it amounts to the same as
adding entries to the fstab ....
Mount(8) doesn't (and shouldn't) know anything about the automount
master map or automount itself since it isn't involved in the automount
function (other than to be called upon to perform a mount) and it would
add unacceptable dependencies, possibly circular, to mount itself.
Umm ... you may be able to get different behavior by using a direct
mount map instead of an indirect mount map. But if you have very large
maps that could introduce, possibly too much, additional overhead.
Ian
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-03-27 4:06 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-28 22:53 stat -L triggering mount (behavior change starting with 2.6.38-rc1) Leonardo Chiquitto
2011-04-01 4:27 ` Ian Kent
2011-04-01 4:55 ` Ian Kent
2011-04-01 4:38 ` Ian Kent
2011-04-01 12:13 ` Leonardo Chiquitto
2011-04-01 9:19 ` David Howells
2011-04-01 12:20 ` Leonardo Chiquitto
2011-04-01 14:27 ` David Howells
2011-08-03 14:16 ` Leonardo Chiquitto
2013-03-26 12:56 ` toto
2013-03-26 20:41 ` Leonardo Chiquitto
2013-03-27 0:13 ` Guillaume Apostoly
2013-03-27 4:06 ` Ian Kent
-- strict thread matches above, loose matches on Subject: below --
2011-03-30 16:19 Leonardo Chiquitto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).