Bug 961299 - Systemd and autofs inconsistence in mount
Summary: Systemd and autofs inconsistence in mount
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-09 11:24 UTC by Pavel Alexeev
Modified: 2015-06-29 11:56 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-06-29 11:56:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Pavel Alexeev 2013-05-09 11:24:42 UTC
Description of problem:
# cat /etc/auto.master.d/m-n-p-y.autofs 
/mnt/net /etc/auto.master.d/maps/m-n-p-y.map users,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8 --timeout=3

Note on --timeout option - I want samba share to be automatically unmounted after some period.

Map file:
# cat /etc/auto.master.d/maps/m-n-p-y.map
m -fstype=cifs ://192.168.100.199/maps
n -fstype=cifs ://192.168.100.199/distr
p -fstype=cifs ://192.168.100.199/Share
y -fstype=cifs ://192.168.100.199/updater

# systemctl restart autofs.service

Log:
May  9 15:20:26 localhost systemd[1]: Cannot add dependency job for unit mdmonitor-takeover.service, ignoring: Unit mdmonitor-takeover.service failed to load: No such file or directory. See system logs and 'systemctl status mdmonitor-takeover.service' for details.
May  9 15:20:26 localhost systemd[1]: Starting Automounts filesystems on demand...
May  9 15:20:26 localhost systemd[1]: Started Automounts filesystems on demand.
May  9 15:20:26 localhost automount[27237]: key "s" not found in map source(s).
May  9 15:20:26 localhost kernel: [13629.039971] CIFS VFS: cifs_mount failed w/return code = -11
May  9 15:20:26 localhost automount[27237]: key "dmp" not found in map source(s).
May  9 15:20:30 localhost systemd[1]: Unit mnt-net-y.mount entered failed state
May  9 15:20:33 localhost systemd[1]: Unit mnt-net-m.mount entered failed state
May  9 15:20:37 localhost systemd[1]: Unit mnt-net-m.mount entered failed state
May  9 15:20:40 localhost systemd[1]: Unit mnt-net-m.mount entered failed state
May  9 15:20:45 localhost systemd[1]: Unit mnt-net-m.mount entered failed state
May  9 15:20:48 localhost systemd[1]: Unit mnt-net-m.mount entered failed state
May  9 15:20:51 localhost systemd[1]: Unit mnt-net-y.mount entered failed state
May  9 15:20:54 localhost systemd[1]: Unit mnt-net-n.mount entered failed state
May  9 15:20:59 localhost systemd[1]: Unit mnt-net-n.mount entered failed state

"Unit mnt-net-*.mount entered failed state" emited continiusely.

# systemctl status mnt-net-p.mount
mnt-net-p.mount - /mnt/net/p
   Loaded: loaded (/etc/fstab)
   Active: active (mounted) (Result: exit-code) since Чт. 2013-05-09 15:22:10 MSK; 9s ago
    Where: /mnt/net/p
     What: //192.168.100.199/Share
  Process: 1115 ExecMount=/bin/mount //192.168.100.199/Share /mnt/net/p -t cifs -o users,guest,hard,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8 (code=exited, status=32)

But thay seams mounted:
# mount | grep /mnt/net
/etc/auto.master.d/maps/m-n-p-y.map on /mnt/net type autofs (rw,relatime,fd=18,pgrp=27237,timeout=3,minproto=5,maxproto=5,indirect)
//192.168.100.199/Share on /mnt/net/p type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,sec=ntlmssp,cache=strict,unc=\\192.168.100.199\Share,domain=WIN-AWL2AH1RL87,uid=500,forceuid,gid=500,forcegid,addr=192.168.100.199,file_mode=0666,dir_mode=0777,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)
//192.168.100.199/distr on /mnt/net/n type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,sec=ntlmssp,cache=strict,unc=\\192.168.100.199\distr,domain=WIN-AWL2AH1RL87,uid=500,forceuid,gid=500,forcegid,addr=192.168.100.199,file_mode=0666,dir_mode=0777,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)
//192.168.100.199/updater on /mnt/net/y type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,sec=ntlmssp,cache=strict,unc=\\192.168.100.199\updater,domain=WIN-AWL2AH1RL87,uid=500,forceuid,gid=500,forcegid,addr=192.168.100.199,file_mode=0666,dir_mode=0777,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)
//192.168.100.199/maps on /mnt/net/m type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,sec=ntlmssp,cache=strict,unc=\\192.168.100.199\maps,domain=WIN-AWL2AH1RL87,uid=500,forceuid,gid=500,forcegid,addr=192.168.100.199,file_mode=0666,dir_mode=0777,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)

Mountpoints accessible.

So, I think if mountpoints managed by autofs it must not be monitored to be mounted by systemd.

Version-Release number of selected component (if applicable):
# rpm -q autofs systemd
autofs-5.0.7-13.fc18.x86_64
systemd-201-2.fc18.5.x86_64

How reproducible:
Always

Comment 1 Harald Hoyer 2013-06-03 11:52:39 UTC
Do you have your mountpoints defined in /etc/fstab _and_ /etc/auto.master.d/m-n-p-y.autofs ???


# systemctl status mnt-net-p.mount
mnt-net-p.mount - /mnt/net/p
   Loaded: loaded (/etc/fstab) <------------------

Comment 2 Pavel Alexeev 2013-06-13 20:23:31 UTC
Indeed.
But in /etc/fstab they listed with noauto option:

# cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Sun Oct  2 14:54:05 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=74c652da-2859-4b43-a6ab-6b265d5da89c       /                       ext4    defaults        1 1
UUID=e4e5c566-ffd6-406b-9d4c-2fb896366ec6       /boot                   ext4    defaults        1 2
UUID=c3ffffc2-069b-4a54-8b63-16e383b93c5a       /home                   ext4    defaults        1 2
UUID=a65351d7-a3dd-443e-9b21-f84a4bf731f6       swap                    swap    defaults,pri=10 0 0
#/root/addon.swap                               swap                    swap    defaults        0 0

//192.168.100.199/updater                       /mnt/net/y              cifs    users,noauto,_netdev,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8  0 0
//192.168.100.199/Share                         /mnt/net/p              cifs    users,noauto,_netdev,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8  0 0
//192.168.100.199/distr                         /mnt/net/n              cifs    users,noauto,_netdev,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8  0 0
//192.168.100.199/maps/GoogleCache              /mnt/net/s              cifs    users,noauto,_netdev,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8  0 0
//192.168.100.199/maps                          /mnt/net/m              cifs    users,noauto,_netdev,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8  0 0
//192.168.100.240/all/dmp                       /mnt/net/dmp            cifs    users,noauto,_netdev,guest,uid=500,gid=500,file_mode=0666,dir_mode=0777,iocharset=utf8  0 0

Comment 3 Lennart Poettering 2013-06-21 11:03:11 UTC
WHat's happening here is that probably some other unit refrenced this mount, and hence caused systemd to pull in the mounts.

Can you paste the output of "systemctl show mnt-net-p.mount" please?

Comment 4 Pavel Alexeev 2013-06-21 18:38:44 UTC
Sure:

Id=mnt-net-p.mount
Names=mnt-net-p.mount
Requires=-.mount
Wants=network-online.target
Conflicts=umount.target
Before=local-fs.target umount.target
After=remote-fs-pre.target network.target network-online.target systemd-journald.socket -.mount
Description=/mnt/net/p
LoadState=loaded
ActiveState=active
SubState=mounted
FragmentPath=/run/systemd/generator/mnt-net-p.mount
SourcePath=/etc/fstab
InactiveExitTimestamp=Пт. 2013-06-21 13:56:04 MSK
InactiveExitTimestampMonotonic=505033031775
ActiveEnterTimestamp=Пт. 2013-06-21 13:56:04 MSK
ActiveEnterTimestampMonotonic=505033031775
ActiveExitTimestamp=Пт. 2013-06-21 13:56:04 MSK
ActiveExitTimestampMonotonic=505032914296
InactiveEnterTimestamp=Пт. 2013-06-21 13:56:04 MSK
InactiveEnterTimestampMonotonic=505032914296
CanStart=yes
CanStop=yes
CanReload=yes
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=no
OnFailureIsolate=no
IgnoreOnIsolate=yes
IgnoreOnSnapshot=no
NeedDaemonReload=no
JobTimeoutUSec=0
ConditionTimestampMonotonic=0
ConditionResult=no
Where=/mnt/net/p
What=//192.168.100.199/Share
Options=rw,nosuid,nodev,noexec,relatime,rw,vers=1.0,sec=ntlmssp,cache=strict,unc=\134\134192.168.100.199\134Share,domain=WIN-AWL2AH1RL87,uid=500,forceuid,gid=500,forcegid,addr=192.168.100.199,file_mode=0666,dir_mode=0777,nounix,serverino,rsize=61440,wsize=65536,actimeo=1
Type=cifs
TimeoutUSec=1min 30s
ControlPID=0
DirectoryMode=0755
Result=success
UMask=0022
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=4096
LimitAS=18446744073709551615
LimitNPROC=62069
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=62069
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
SameProcessGroup=yes
ControlGroupModify=no
ControlGroupPersistent=no
IgnoreSIGPIPE=yes
NoNewPrivileges=no
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
DefaultControlGroup=name=systemd:/system/mnt-net-p.mount
ControlGroups=cpu:/system/mnt-net-p.mount name=systemd:/system/mnt-net-p.mount

Comment 5 Fedora End Of Life 2013-12-21 13:27:27 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Fedora End Of Life 2015-05-29 09:02:51 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Fedora End Of Life 2015-06-29 11:56:39 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.