Hi Khalid, first of all, thanks for looking into the issue.
I am by far no systemd expert, so if I get anything wrong, please correct me :) I do think however, that I know enough to be certain that there is a problem with the package when utilizing systemd as init system. > Have you seen any evidence of corruption on a filesystem? Yes, I can reproduce unclean (un-)mounts on my testing machine (Xeon E3-1245, SSD) when using the original kexec-tools package on every reboot with kexec enabled: [...] [Sat Jun 20 00:05:32 2015] Adding 4194300k swap on /dev/mapper/vg-swap. Priority:-1 extents:1 across:4194300k FS [Sat Jun 20 00:05:32 2015] EXT4-fs (dm-4): 1 orphan inode deleted [Sat Jun 20 00:05:32 2015] EXT4-fs (dm-4): recovery complete [Sat Jun 20 00:05:32 2015] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: (null) [Sat Jun 20 00:05:32 2015] EXT4-fs (dm-3): 5 orphan inodes deleted [Sat Jun 20 00:05:32 2015] EXT4-fs (dm-3): recovery complete [...] Whereas I cannot reproduce this when using my patched package: [...] [Sat Jun 20 00:07:39 2015] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: usrjquota=aquota.user,jqfmt=vfsv1 [Sat Jun 20 00:07:39 2015] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: (null) [Sat Jun 20 00:07:39 2015] Adding 4194300k swap on /dev/mapper/vg-swap. Priority:-1 extents:1 across:4194300k FS [Sat Jun 20 00:07:39 2015] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: (null) [...] Reboot times are roughly the same, only with the current official Jessie package, I get unclean mounts all the time, which in turn suggests, that the filesystem has not been properly unmounted before kexec loaded the new kernel image. > /etc/init.d/kexec script header says: > > # X-Stop-After: umountroot > > which means stop target for /etc/init.d/kexec will not be called until > root fs has been unmounted, at which point all other filesystems must > have already been unmounted. When using SysV init, this is indeed true - however systemd seems to mask the umountroot/umountfs LSB init scripts, which means that they are not considered for dependencies at all. Thus the kexec LSB init script dependency is rendered useless: lrwxrwxrwx 1 root root 9 May 26 08:07 /lib/systemd/system/umountroot.service -> /dev/null lrwxrwxrwx 1 root root 9 May 26 08:07 /lib/systemd/system/umountfs.service -> /dev/null This can also bee seen when checking the unit file (auto-)generated by systemd-sysv: /run/systemd/generator.late/kexec-load.service: # Automatically generated by systemd-sysv-generator [Unit] SourcePath=/etc/init.d/kexec-load Description=LSB: Load kernel image with kexec Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target shutdown.target After=local-fs.target remote-fs.target kexec.service Conflicts=shutdown.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SysVStartPriority=2 ExecStart=/etc/init.d/kexec-load start ExecStop=/etc/init.d/kexec-load stop /run/systemd/generator.late/kexec.service: # Automatically generated by systemd-sysv-generator [Unit] SourcePath=/etc/init.d/kexec Description=LSB: Execute the kexec -e command to reboot system Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target shutdown.target Conflicts=shutdown.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SysVStartPriority=1 ExecStart=/etc/init.d/kexec start ExecStop=/etc/init.d/kexec stop So basically kexec.service depends on kexec-load.service to be stopped before itself, which is okay, because the kernel image needs to be loaded before doing the actual kexec reboot. However there are no other dependencies whatsoever on the filesystem or other services, which basically means that kexec.service will be in a race with other services being shut down at the same time. If you get lucky the other services have been stopped before kexec gets executed, otherwise you are not (and the observed inconsistencies may occur) :( > Rebooting the system with "reboot" calls the target reboot. That is correct. >If one invokes the target kexec directly, their intent is to kexec immediately > (same as exceuting "kexec -e" which does not do an orderly shutdown). > Orderly shutdown is meant to happen when reboot is called, not when > kernel is kexec'd explicitly by the user. I do not agree with this change. This however, is not. I guess you are confusing kexec.service (which is the autogenerated unit for your LSB kexec script) with the systemds' builtin kexec.target (which will be used when issuing 'systemctl kexec') - the according unit file can be found here: /lib/systemd/system/kexec.target: # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Reboot via kexec Documentation=man:systemd.special(7) DefaultDependencies=no Requires=systemd-kexec.service After=systemd-kexec.service AllowIsolate=yes [Install] Alias=ctrl-alt-del.target So kexec.target depends on systemd-kexec.service: /lib/systemd/system/systemd-kexec.service: # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Reboot via kexec Documentation=man:systemd-halt.service(8) DefaultDependencies=no Requires=shutdown.target umount.target final.target After=shutdown.target umount.target final.target [Service] Type=oneshot ExecStart=/bin/systemctl --force kexec This service does the actual kexec invocation and depends on shutdown.target, umount.target, final.target, which ensures that all filesystems have been properly unmounted beforehand. So, in fact 'systemctl kexec' is the proper way of doing a kexec reboot with systemd, at least I think it's the way systemd developers expect kexec reboots to happen (otherwise this builtin unit would make no sense at all). To summarize: Your LSB dependencies in the init scripts are ok for SysV and ensure a correct handling of filesystem unmounts. However when using systemd (which is the default init system in Jessie), the dependencies are void/nonexistant/wrong, because those dependencies are masked by systemd (because systemd does it's own handling of mounts). My patch fixes this issue, so kexec reboots (only) via 'systemctl kexec' are correctly/safely handled. However it also breaks the old (SysV) behavior, because reboots via 'reboot'/'systemctl reboot'/etc. will not utilize kexec, even if it is enabled in /etc/default/kexec. I guess the 'right' way to do it would be to keep the old behavior for compatibility reasons, which means the patch should be revised. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
