[systemd-devel] hanging reboot
sergei.franco at gmail.com
Thu Mar 9 00:00:55 UTC 2017
Thank you very much for pointing out the "After" vs "Before", as in for
ExecStop to run Before filesytem is unmounted it must be configured as
This fixes the Ubuntu unattended upgrades unit that prevents from hanging.
What I would like to address for future problems like this is how to have a
global timeout where systemd gives up and reboots anyway (regardless the
state of the units)? Even if it is a dirty reboot.
Thank you very much!
On 8 March 2017 at 18:04, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> 08.03.2017 03:05, Sergei Franco пишет:
> > Hello,
> > I am revisiting the issue (since it has been completely ignored by
> > people).
> Which issue? "hanging reboot" is too generic title, it can be anything.
> > The actual attempt at fixing this issue did not succeed.
> > The official ubuntu fix does not resolve the hang.
> Oh, you mean Ubuntu specific problem? Do you have evidences that it is
> caused by upstream bug?
> > The problem is that the unattended-upgrades script relies on /var/run
> > mounted, if the /var/ is a separate filesystem it gets unmounted and thus
> > hanging the script (where it waits for the lock to be available).
> How is it systemd problem?
> > Here is the official ubuntu unattended-upgrade-shutdown unit:
> > [Unit]
> > Description=Unattended Upgrades Shutdown
> > DefaultDependencies=no
> > Before=shutdown.target reboot.target halt.target network.target
> > local-fs.target
> Well, you order if before local-fs.target, which means it is stopped
> after local-fs.target. You get exactly what you ask for. If this is
> wrong, fix unit definition, but we do not really know what is
> appropriate for this service.
> > Documentation=man:unattended-upgrade(8)
> > [Service]
> > Type=oneshot
> > RemainAfterExit=yes
> > ExecStop=/usr/share/unattended-upgrades/unattended-upgrade-shutdown
> > TimeoutStopSec=900
> > [Install]
> > WantedBy=shutdown.target
> > It appears no one who is involved in this fix understands systemd (which
> > very worrying!).
> > How does one would fix this unit so it is ran before the file systems get
> > unmounted?
> Order it
> > Also, how does one configure systemd to have a global timeout to
> > a reboot? Hanging on reboot is OK for a laptop but is completely
> > unacceptable for a server.
> I usually encountered hanging reboot due to inaccessible NFS server and
> in my experience system did reset after watchdog expired.
> > Best regards.
> > Sergei.
> > On 2 March 2017 at 10:21, Sergei Franco <sergei.franco at gmail.com> wrote:
> >> Hello,
> >> I submitted similar question but it got stuck with moderators due to
> >> screen shot size.
> >> The actual bug report (on ubuntu side) is here:
> >> https://bugs.launchpad.net/ubuntu/+source/unattended-
> >> My main question is actually how to configure systemd to have global
> >> timeout on reboot, so no future services will hang it?
> >> The reboots must happen regardless if systemd can start/stop services. I
> >> am even happy to wait 15 min as long as reboots do happen. Otherwise if
> >> reboots are not guaranteed it is an epic failure on design of the
> >> Thanks a lot!
> >> Sergei.
> >> On 2 March 2017 at 04:42, Hajo Locke <Hajo.Locke at gmx.de> wrote:
> >>> Hello list,
> >>> sometimes i have problems rebooting some machine. i think in that cases
> >>> shutting down some services fails and machine stays somewhere between
> >>> and death.
> >>> Unfortunately my ssh window closes at first and no reconnect is
> >>> it only tells "Connection refused".
> >>> If this happens, then i have to do a call to someone who works in
> >>> datacenter and resets my machine by hand.
> >>> I would like to keep sshd alive as long as possible to reconnect and
> >>> this by hand.
> >>> How can i achive this?
> >>> System is Ubuntu 16.04 with systemd 229-4ubuntu16
> >>> I googled some similiar questions and tried but without success.
> >>> What could i do?
> >>> Thanks,
> >>> Hajo
> >>> _______________________________________________
> >>> systemd-devel mailing list
> >>> systemd-devel at lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> > _______________________________________________
> > systemd-devel mailing list
> > systemd-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the systemd-devel