Yay, I found another behavioural difference between just running Debian
(classic, that is, sysvinit withOUT elogind) and Debian with elogind (to
satisfy certain packages’ dependencies, I certainly do not need any of
its functionality!).
This is in the same manner as #919694 (*why* is that still unfixed‽)
and #949698 (now fixed).
I’m working on an IBM Thinkpad X61, which has a “suspend to disc”
symbol printed in blue on the F12 key, which means Fn-F12 would, if
the operating system handles it, suspend to hard disc.
This key never did anything without elogind installed.
I just hit it by accident. The system immediately(!) became fully
unresponsible (could not even move the mouse pointer), but my xterm
with tail -F /var/log/syslog captured a number of lines. The first
three of it were:
Oct 4 01:09:22 tglase-nb vmunix: [1043273.743227] elogind-daemon[1640]: Hibernate key pressed.
Oct 4 01:09:22 tglase-nb vmunix: [1043273.747348] elogind-daemon[1640]: Hibernating...
Oct 4 01:09:22 tglase-nb vmunix: [1043273.749104] PM: Image not found (code -22)
This is clear evidence that elogind *actively* captured that keypress
and did something not normal (i.e. not present on a standard pre-systemd
system without elogind). Whatever it did apparently failed, but it STILL
proceeded to crash the whole system (with the screen flickering a number
of times and then the system suddenly powering off).
Upon starting it again (losing all my state, unsaved files I was writing,
and all that), I’ve seen the usual messages about problems with a dirty
filesystem, so it’s evident that elogind positively, actively crashed the
system instead of shutting it down cleanly, or, (which would have been the
correct thing to do) just returning and not doing *anything* after that
whatever it tried to do failed.
The other log messages I saw flickering by in xterm are, of course, not
preserved (ext4 “helpfully” inserted a whole block of NUL characters into
my /var/log/syslog file, though).
Now, from evidence to guesswork: from reading the log, I’m guessing it
actually *did* try to suspend to disc, failing to do so (naturally, as
this system is not set up for it, namely, the RAM is much larger than
the swap space, and no equivalent to Windows® 2000’s HIBERFIL.SYS was
set up either, mostly because I do not even *use* hibernation, nor do
I *want* it). But, like I said, that failure was mishandled.
Considering I actually lost (a small amount of) user data, I feel the
severity justified.
I’ve also just looked at the elogind.conf file I was told to change in
one of the two other bugreports I mentioned above. There is some config
regarding hibernation, so I guess, now that I know about the problem,
I could just turn off as a WORKAROUND *ONLY* (I *assume* changing
#HandleHibernateKey=hibernate
to HandleHibernateKey=ignore
might do the trick) but then I wonder why this is not ignored by default,
and the failure to handle suspend-to-disc failure is still present (and
someone should probably check if systemd similarily suffers).
Anyway, this bugreport should point out something more: People *need*
to install libpam-elogind to satisfy package dependencies, which forces
elogind installation alongside; elogind now runs a dæmon which changes
system behaviour (compared to regular pre-systemd Debian) in unpredictable
ways, much to users’ detriment.
I believe there exist users who would wish for all these features, but
to me, who doesn’t even need them in the first place, a way of satisfying
packages without piling new bugs onto the system is direly needed.
Sorry for any grumpiness here, I’ve just lost some work and quite an
amount of session state and it’s half past one in the bloody night and
I visited the manuls (pallas cats) in the zoo earlier which provide for
appropriate grumpiness; I don’t intend any insult or something towards
any living being (just towards software).