Bug#971644: elogind: accidentally hitting Fn-F12 crashes the system (dirty filesystem)

2020-10-04 Thread Thorsten Glaser
Mark Hindley dixit:

>Forwarded upstream.

Thanks.

>> Ibve 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)
>
>Yes, I would expect that to be a good workaround in your case.

OK, I’ve changed that settng now, also for suspend, just to be safe.

>> but then I wonder why this is not ignored by default,
>
>If there is a consensus that the default should be different, then I am
>happy to change it.

That’s fair. I don’t know all the implicatons of this.

(And sorry again for being annoyed last night. I’ve had a feeling
that elogind, being forked from systemd, has become what it was
meant to avoid. But, yes, we share a common goal; if those tools
we have are lacking they can be improved.)

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………



Bug#971644: elogind: accidentally hitting Fn-F12 crashes the system (dirty filesystem)

2020-10-04 Thread Mark Hindley
Control: forwarded -1 https://github.com/elogind/elogind/issues/177

Thorsten,

Many thanks for this.

On Sun, Oct 04, 2020 at 01:30:53AM +0200, Thorsten Glaser wrote:
> Package: elogind
> Version: 243.7-1+debian1
> Severity: critical
> Justification: causes serious data loss
> X-Debbugs-Cc: t...@mirbsd.de

[..]

> 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).

I fully agree that this should be handled better.

Forwarded upstream.

[...]

> 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
> toHandleHibernateKey=ignore
> might do the trick)

Yes, I would expect that to be a good workaround in your case.

> but then I wonder why this is not ignored by default,

If there is a consensus that the default should be different, then I am happy to
change it.

Best wishes

Mark



Bug#971644: elogind: accidentally hitting Fn-F12 crashes the system (dirty filesystem)

2020-10-03 Thread Thorsten Glaser
Package: elogind
Version: 243.7-1+debian1
Severity: critical
Justification: causes serious data loss
X-Debbugs-Cc: t...@mirbsd.de

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).


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages elogind depends on:
ii  dbus 1.12.20-1
ii  debconf  1.5.74
ii  libacl1  2.2.53-8
ii  libc62.31-3
ii  libcap2  1:2.43-1
ii  libelogind0  243.7-1+debian1
ii  libselinux1  3.1-2
ii  libudev1 246.6-1
ii  lsb-base 11.1.0

Versions of packages elogind recommends:
ii  libpam-elogind  243.7-1+debian1
ii  policykit-1 0.105-29

elogind suggests no packages.

-- Configuration Files: