<div dir="ltr"><div><div><div><div><div>Hello! </div>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 After :). </div>This fixes the Ubuntu unattended upgrades unit that prevents from hanging. </div>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. </div>Thank you very much! </div>Sergei. </div><div class="gmail_extra"> <div class="gmail_quote">On 8 March 2017 at 18:04, Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">08.03.2017 03:05, Sergei Franco пишет: > Hello, > > I am revisiting the issue (since it has been completely ignored by systemd > 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 being > 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 --debug > TimeoutStopSec=900 > > [Install] > WantedBy=shutdown.target > > It appears no one who is involved in this fix understands systemd (which is > very worrying!). > > How does one would fix this unit so it is ran before the file systems get > unmounted? > Order it After=local-fs.target > > Also, how does one configure systemd to have a global timeout to guarantee > 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. <div class="HOEnZb"><div class="h5"> > > Best regards. > > > Sergei. > > > > On 2 March 2017 at 10:21, Sergei Franco <<a href="mailto:sergei.franco@gmail.com">sergei.franco@gmail.com</a>> 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: >> <a href="https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1661611" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1661611</a> >> >> 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 system. >> >> Thanks a lot! >> >> >> Sergei. >> >> On 2 March 2017 at 04:42, Hajo Locke <<a href="mailto:Hajo.Locke@gmx.de">Hajo.Locke@gmx.de</a>> 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 life >>> and death. >>> Unfortunately my ssh window closes at first and no reconnect is possible, >>> 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 fix >>> 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 >>> <a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a> >>> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> >>> >> >> > > > > _______________________________________________ > systemd-devel mailing list > <a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> > _______________________________________________ systemd-devel mailing list <a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </div></div></blockquote></div> </div>