[systemd-devel] systemd automounts

[Mirco Tischler]

2011/8/2 Steve Dickson <SteveD at redhat.com>:
>
>
> On 08/02/2011 04:35 AM, Mirco Tischler wrote:
>> 2011/8/2 Steve Dickson <SteveD at redhat.com>:
>>>
>>>
>>> On 08/01/2011 09:10 PM, Mirco Tischler wrote:
>>>> Hi
>>>> 2011/8/2 Steve Dickson <SteveD at redhat.com>:
>>>>>>
>>>>>> Yes, this looks like a good usecase.
>>>>>>
>>>>>> Hmm, does the automount point work after boot?
>>>>> It seems so, because if I restart nfs-idmap.service the
>>>>> service comes up.
>>>>>
>>>>>>
>>>>>> How does the output of "systemctl list-units" look like for the
>>>>>> automount and mount unit?
>>>>>>
>>>>> attached.
>>>>>
>>>>> steved.
>>>>>
>>>> The attached output indicates that your automount unit isn't started,
>>>> and I can't see anything causing it to start in your unit files
>>>> either. You can verify this with systemctl status
>>>> var-lib-nfs-rpc_pipefs.automount.
>>> It appears you are correct. systemctl status var-lib-nfs-rpc_pipefs.automount
>>> show the status not being started.
>>>
>>>> Note that After= is only an ordering information and doesn't cause the
>>>> unit to be started. Only if the automount is started anyway through
>>>> some other path, the After= line causes the service to wait until the
>>>> automount point is started.You may need to add a line
>>>> Wants=var-lib-nfs-rpc_pipefs.automount to your service file.
>>>>
>>>> Does that help you?
>>> Adding that wants does start var-lib-nfs-rpc_pipefs.automount but
>>> now I'm getting two mounts...
>>>
>>> # mount | grep rpc
>>> systemd-1 on /var/lib/nfs/rpc_pipefs type autofs (rw,relatime,fd=16,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
>>> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
>>>
>>> or is that normal for automounts?
>>>
>>> steved.
>>>
>> Yup that's normal. the systemd-1 is the automount point.
> Thanks for this tip... but things are still no quite right...
>
> the "Starting RPC Pipe File System" (i.e. the mount of  /var/lib/nfs/rpc_pipefs)
> was happening later than the "Starting Name to UID/GID mapping for NFSv4"
> (i.e. the nfs-idmap.service) so I added back the After=var-lib-nfs-rpc_pipefs.automount
> line nfs-idmap.service which didn't seem to work... Looking at the booting messages,
> the nfs-idmap.service is still being started before the automount.
>
> How I do I guarantee the automount happens and finish before nfs-idmap.service
> is started?
This is not how automount works. The real fs is only mounted when the
first acces is done which is of cause
after the service begins to start. The access is then blocked until
the fs is mounted.
However I'm starting to think automount isn't what you want at all.
Your nfs-idmap.service is started on boot and needs the rpc fs during
service startup so it doesn't make a lot of sense to delay the start
of the service with an automount point. Automount is more useful IMO
when the fs isn't usually used during boot.
Why don't you discard the automount unit and instead reference the
actual mount unit in your service file with After= and Wants= lines.
Does that make sense to you?
>
> Also now when I reboot the system hangs for a bit due to the following
> problem:
>
> [  272.510946] systemd[1]: var-lib-nfs-rpc_pipefs.mount mounting timed out. Killing.
> [  362.511271] systemd[1]: var-lib-nfs-rpc_pipefs.mount mount process still around after SIGKILL. Ignoring.
> [  362.609307] systemd[1]: Unit var-lib-nfs-rpc_pipefs.mount entered failed state.
>
> So it appears the ordering of the shutdown is not quite right either...
I'm not sure if this is the problem but you have
DefaultDependencies=no in your unit files. Do you really need this? If
yes you might need to add Conflicts=shutdown.target to make this work
>
> steved.

Mirco