On 11/03/2014 08:45 PM, Khalid Aziz wrote:
??? This is how it is supposed to work. Return value from pidof is 0 if
at least one systemd process is found irrespective of its pid. If return
value is 0, I want to check if the current command is reboot or
something else. If it is reboot, do a kexec reboot. If it is not, do not
load a kexec'able kernel which will result in normal
reboot/shutdown/.... If return value from pidof is 1, system is not
running systemd. If that is the case, we proceed with kexec reboot by
loading a kexec'able kernel. On a SysV init based system, kexec-load
script will be invoked on a reboot only.
The point is there is not a single process called "systemd" when
"systemd-sysv" is installed. It is simply called "init". There is no
"systemd" in process table. So pidof returns 1, not 0, which renders the
code inside the if check moot and results in a reboot instead of shutdown.
Checking for process called "systemd" would be still potentially
misleading anyway, with all the bells and whistles of systemd, there may
be a systemd but not as PID 1, so it is not the best approach even if it
worked.
Second approach reads the output of "systemctl is-system-running"
command. This command will print "stopping" if systemd is the init and
the system is shutting down or rebooting. Otherwise (if systemd is not
init or systemd is not installed at all, so the command doesn't exist)
it will fail so the if check will fail.
Does this approach work if someone installs systemd as well as SysV init
but disables systemd? I played with a few combinations of both installed
on a system with different ways of disabling them and I found I could
not rely upon presence of systemctl as a reliable indicator of whether
systemd is installed and enabled or not.
Yes, I tested both versions of the patch with both sysvinit and systemd
as pid 1, and with systemd-sysv packages installed or not installed, and
systemd package installed or not installed, all combinations. Lack of a
systemctl command is not a problem, as a nonexistent or failed command
will not print "stopping" to stdout. It would worked OK if there wasn't
a better recommendation from systemd maintainers.
First version (v1), reads /proc/1/comm to check if it's systemd or init.
A potential problem with this approach is that the /proc/<pid>/comm
interface works on only linux 2.6.33+. I don't know if it's really a
problem.
Relying upon systemd being PID 1 is not a good idea. One of these days
someone will come up with reasons and ways to run systemd as PID other
than 1 and kexec will break again.
Well, I don't think systemd running as non PID 1 would mess with rc6.d
scripts so it shouldn't be a problem we should watch out for.
Anyway, best approach seems to be listening the recommendation of
systemd maintainers instead of inventing our own methods. In the bug
I've linked in the previous message:
On Mon, 03 Nov 2014 14:19:07 +0100 Michael Biebl <bi...@debian.org> wrote:
The systemd system runtime directory is only created when systemd is the
active PID 1. Could you elaborate why you think this approach is
fragile? If those two tests (for systemd and upstart) would be brittle,
we'd have a problem, since they are used all over the place.
I didn't tested it but I can't see any reason why it shouldn't work.
Thanks for your time and involvement.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
