Hello! 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 :). 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! Sergei. On 8 March 2017 at 18:04, Andrei Borzenkov <arvidj...@gmail.com> wrote: > 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. > > > > > Best regards. > > > > > > Sergei. > > > > > > > > On 2 March 2017 at 10:21, Sergei Franco <sergei.fra...@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- > upgrades/+bug/1661611 > >> > >> 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 <hajo.lo...@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 > 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 > >>> systemd-devel@lists.freedesktop.org > >>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel > >>> > >> > >> > > > > > > > > _______________________________________________ > > systemd-devel mailing list > > systemd-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel