Systemd on vivid beta

Colin Law clanlaw at gmail.com
Sat Mar 14 11:21:28 UTC 2015


On 13 March 2015 at 10:02, Colin Law <clanlaw at gmail.com> wrote:
> On 12 March 2015 at 13:30, Tom H <tomh0665 at gmail.com> wrote:
>> On Thu, Mar 12, 2015 at 7:51 AM, Colin Law <clanlaw at gmail.com> wrote:
>>>
>>> The plot thickens!
>>> Having worked around the fact that syslog closes down too soon by
>>> adding diy logging to a file from the script I find that the culprit
>>> is a line of the form
>>> umount -l /path/to/mountpoint
>>> where this was orginally mounted using something like
>>> mount -t cifs -o credentials=***,user,rw,uid=1000 //192.168.1.nnn/path
>>> /path/to/mountpoint
>>>
>>> The umount command takes anything up to 2 minutes to complete.
>>> If I use systemctl stop to stop the service it runs straight through
>>> without delay.  I wonder whether some networking service has also been
>>> stopped too soon and umount is timing out waiting for a response.
>>
>> I agree with the "network's gone down before the unmount" theory. I'm
>> pretty sure that I've hit this problem with an nfs mount.
>>
>> If you're using NM, there's just been an update to adjust the
>> dependencies of NetworkManager-wait-online.service and enable it that
>> might resolve your problem.
>
> Thanks for the suggestion, I am using NM, but enabling that service
> did not appear to make any difference.  Looking at the information I
> could find on that it seemed that the effect is the same as including
> After=network-online.target and Wants=network-online.target in the
> service file, and they are there already.
>
> However I think maybe the problem is more fundamental than I thought.
> I find that if I just manually mount a cifs share ( sudo mount -t cifs
> ...) and shutdown that I get the same delay on shutdown, whereas if I
> do the same in an upstart boot then there is no delay.  That seems
> like a reportable bug to me, so I have reported it.
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1431774

In case anyone is interested this was caused by a missing dependency
in the NetworkManager service file, allowing NM to shutdown too early.
Fixed in today's network-manager update.

Colin




More information about the ubuntu-users mailing list