Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#851402: failed unmounting /var during shutdown
392 views
Skip to first unread message
Daniel Pocock
Jan 14, 2017, 10:40:21 AM1/14/17
to
Package: systemd
Version: 232-8
Severity: important
The box is running stretch, updated from jessie yesterday.
When the box shuts down, it unmounts all the filesystems.
When it gets to /var there is a warning: Failed unmounting /var
I wrote a little wrapper script to put in place of /bin/umount, it calls
lsof to show what is going on before the real umount call
The only open files on /var at the time of unmounting appear to be
journalctl files
Is this expected? Is some manual configuration needed to make sure /var
is unmounted later or should systemd / journald behave better in this
situation?
Version: 232-8
Severity: important
The box is running stretch, updated from jessie yesterday.
When the box shuts down, it unmounts all the filesystems.
When it gets to /var there is a warning: Failed unmounting /var
I wrote a little wrapper script to put in place of /bin/umount, it calls
lsof to show what is going on before the real umount call
The only open files on /var at the time of unmounting appear to be
journalctl files
Is this expected? Is some manual configuration needed to make sure /var
is unmounted later or should systemd / journald behave better in this
situation?
Michael Biebl
Jan 15, 2017, 4:30:02 PM1/15/17
to
On Sat, 14 Jan 2017 16:37:54 +0100 Daniel Pocock <dan...@pocock.pro> wrote:
> Package: systemd
> Version: 232-8
> Severity: important
>
>
> The box is running stretch, updated from jessie yesterday.
>
> When the box shuts down, it unmounts all the filesystems.
>
> When it gets to /var there is a warning: Failed unmounting /var
>
>
> I wrote a little wrapper script to put in place of /bin/umount, it calls
> lsof to show what is going on before the real umount call
>
> The only open files on /var at the time of unmounting appear to be
> journalctl files
>
> Is this expected? Is some manual configuration needed to make sure /var
> is unmounted later
/var should be unmounted later, after the final killing spree by
> Package: systemd
> Version: 232-8
> Severity: important
>
>
> The box is running stretch, updated from jessie yesterday.
>
> When the box shuts down, it unmounts all the filesystems.
>
> When it gets to /var there is a warning: Failed unmounting /var
>
>
> I wrote a little wrapper script to put in place of /bin/umount, it calls
> lsof to show what is going on before the real umount call
>
> The only open files on /var at the time of unmounting appear to be
> journalctl files
>
> Is this expected? Is some manual configuration needed to make sure /var
> is unmounted later
systemd-shutdown (see man 8 systemd-shutdown). I don't suppose you
actually had a dirty fs after shutdown?
As for /var being unmounted earlier during shutdown, this is most likely
happening because of var.mount conflicting with umount.target and
systemd-journald.service not having an explicit ordering against var.mount
I suppose you have persistent journal enabled, i.e. journald is writing
to /var/log/journal?
Fwiw, I think the warning is harmless (as said, systemd-shutdown will
unmount /var).
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
Jan 15, 2017, 9:40:02 PM1/15/17
to
Control: tags -1 + moreinfo
Am 15.01.2017 um 22:20 schrieb Michael Biebl:
> /var should be unmounted later, after the final killing spree by
> systemd-shutdown (see man 8 systemd-shutdown). I don't suppose you
> actually had a dirty fs after shutdown?
>
> As for /var being unmounted earlier during shutdown, this is most likely
> happening because of var.mount conflicting with umount.target and
> systemd-journald.service not having an explicit ordering against var.mount
>
>
> I suppose you have persistent journal enabled, i.e. journald is writing
> to /var/log/journal?
Would be good if you can provide a verbose debug log from the shutdown:
/usr/share/doc/systemd/README.Debian.gz → check how to generate a
shutdown-log.txt
That log should help answer the above questions.
Am 15.01.2017 um 22:20 schrieb Michael Biebl:
> /var should be unmounted later, after the final killing spree by
> systemd-shutdown (see man 8 systemd-shutdown). I don't suppose you
> actually had a dirty fs after shutdown?
>
> As for /var being unmounted earlier during shutdown, this is most likely
> happening because of var.mount conflicting with umount.target and
> systemd-journald.service not having an explicit ordering against var.mount
>
>
> I suppose you have persistent journal enabled, i.e. journald is writing
> to /var/log/journal?
/usr/share/doc/systemd/README.Debian.gz → check how to generate a
shutdown-log.txt
That log should help answer the above questions.
Michael Biebl
Jan 18, 2017, 5:40:02 AM1/18/17
to
Control: forwarded -1 https://github.com/systemd/systemd/issues/867
Control: tags -1 - moreinfo
Control: severity -1 normal
Ok this seems to be https://github.com/systemd/systemd/issues/867
Marking accordingly. As we unmount /var in the systemd-shutdown binary,
I'm downgrading the severity (as it's mostly a cosmetic issue)
Control: tags -1 - moreinfo
Control: severity -1 normal
Marking accordingly. As we unmount /var in the systemd-shutdown binary,
I'm downgrading the severity (as it's mostly a cosmetic issue)
0 new messages