Devuan bug report logs - #920
xorg dpms activation causes server exit on i915

Reply or subscribe to this bug.

Toggle useless messages

---

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

Package: devuan-desktop
Severity: normal
X-Debbugs-Cc: bobjohnbowles@gmail.com

Dear Maintainer,


   * What led up to the situation?
Distribution upgrade from Devuan daedalus to excalibur.
Since the upgrade I have found the system automatically logs out after
a short period of inactivity, terminating all open applications, and
reverting to the slim login screen.
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
I have tried removing the xfce4-power-manager and disabling screenlock.

   * What was the outcome of this action?
These efforts have had no positive effect.
I did find, prior to completely removing it, that changing the power
manager's settings made things infinitely worse, in that gui login
immediately triggers logout, the system becomes unusable. Recovery was
only possible from the command line terminal login by deleting the
power manager's configuration file.

   * What outcome did you expect instead?
I wanted to prevent the system automatically logging out.



-- System Information:
Distributor ID: Devuan
Description: Devuan GNU/Linux 6 (excalibur)
Release: 6
Codename: excalibur
Architecture: x86_64

Kernel: Linux 6.12.48+deb13-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

---

Message #10 received at 920@bugs.devuan.org (full text, mbox, reply):

1) I checked the BIOS in case something had been altered, and it did
not seem to have been. Just to be on the safe side I disabled all BIOS
power management facilities. This had no effect.

2) I rolled back to Daedalus and the problem stopped occurring. It
does not narrow things down much, but this does seem to be something
to do with the Excalibur distribution upgrade, and nothing else.

FWIW I have seen reports elsewhere of similar problems with other
distros based on Debian Trixie, not sure if this might be related.

-- 
Dr RJ Bowles

25 Wellesley Avenue North  Norwich  NR1 4NT
+44 (0)7912 297662

Skype: bob.john.bowles
Email: bobjohnbowles@gmail.com

---

Message #15 received at 920@bugs.devuan.org (full text, mbox, reply):

On Tue, Nov 04, 2025 at 04:48:26PM +0000, Bob Bowles wrote:
> I am using the slim login manager, There seems to be nothing unusual
> in the slim logs, unless messages saying 'unexpected signal 15' tell
> you more than they do me.

Yes, that is it. We need to find where the signal is coming from. 15 is SIGTERM
and so slim exits.

If you think the power management is unnecessary, does

 apt autoremove xfce-power-manager

remove things you need or want?

Same for acpi?

Mark

---

Message #20 received at 920@bugs.devuan.org (full text, mbox, reply):

Bob,

The only ways I can think that SIGTERM will come unsolicited is if the kernel
invokes oom killer.

Does the system get sluggish before slim is killed? Do you have enough memory?
If you run (in an x-terminal)

 watch free -h

does the amount of free memory decrease until the auto logout?

Is there a memory hog at the top of

 top -o %MEM

I will keep thinking of other options.

Mark

---

Message #25 received at 920@bugs.devuan.org (full text, mbox, reply):

Hi,

[ Could you keep 920@bugs.devuan.org in the CC:, please? ]

On Wed, Nov 05, 2025 at 04:59:41PM +0000, Bob Bowles wrote:
> I did the following: login, did some random activity while monitoring
> the memory, then left the terminal open monitoring memory at 16:03,
> near as. Came back at 16:12 and watched while the system logged me
> out. Then I went into console to check the logs, and found the last
> entries in the user.log, timestamped 16:12:52. There is an error
> message from pulseaudio. Could that be it?

Possibly. Let's delve down that rabbit hole.

Does /run exist? What are it's perms?

$ ls -ld /run
drwxr-xr-x 28 root root 1200 Nov  5 06:44 /run

Is it mounted as a tmpfs?

$ df -h /run
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           392M  884K  391M   1% /run

Does run/user/$USER exist and what are it's perms?

$ ls -ld /run/user/$(id -u)
drwx------ 10 mark root 320 Nov  5 16:29 /run/user/1000

From the pulseaudio error you found, I think that may fail. If it fails, why?
Have you got libpam-elogind installed?(I use seatd and consolekit, so I don't
have the correct output to hand, but the following should produce something
useful).

$ dpkg -l libpam-elogind libelogind-compat

Is elogind running?

$ loginctl

Is $XDG_RUNTIME_DIR set?

$ echo $XDG_RUNTIME_DIR
/run/user/1000

By this point we should hopefully have a clearer picture.

Mark

---

Message #30 received at 920@bugs.devuan.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Mark

Everything in your list of queries checks out EXCEPT the group of
/run/user/1000. This has owner and group as bob, instead of owner bob,
group root. This explains the pulseaudio error, but not how/why the
wrong group is assigned.

Please find attached a screenshot of the console session.


Kind Regards   Bob Bowles

On Wed, 5 Nov 2025 at 17:16, Mark Hindley <mark@hindley.org.uk> wrote:
>
> Hi,
>
> [ Could you keep 920@bugs.devuan.org in the CC:, please? ]
>
> On Wed, Nov 05, 2025 at 04:59:41PM +0000, Bob Bowles wrote:
> > I did the following: login, did some random activity while monitoring
> > the memory, then left the terminal open monitoring memory at 16:03,
> > near as. Came back at 16:12 and watched while the system logged me
> > out. Then I went into console to check the logs, and found the last
> > entries in the user.log, timestamped 16:12:52. There is an error
> > message from pulseaudio. Could that be it?
>
> Possibly. Let's delve down that rabbit hole.
>
> Does /run exist? What are it's perms?
>
> $ ls -ld /run
> drwxr-xr-x 28 root root 1200 Nov  5 06:44 /run
>
> Is it mounted as a tmpfs?
>
> $ df -h /run
> Filesystem      Size  Used Avail Use% Mounted on
> tmpfs           392M  884K  391M   1% /run
>
> Does run/user/$USER exist and what are it's perms?
>
> $ ls -ld /run/user/$(id -u)
> drwx------ 10 mark root 320 Nov  5 16:29 /run/user/1000
>
> From the pulseaudio error you found, I think that may fail. If it fails, why?
> Have you got libpam-elogind installed?(I use seatd and consolekit, so I don't
> have the correct output to hand, but the following should produce something
> useful).
>
> $ dpkg -l libpam-elogind libelogind-compat
>
> Is elogind running?
>
> $ loginctl
>
> Is $XDG_RUNTIME_DIR set?
>
> $ echo $XDG_RUNTIME_DIR
> /run/user/1000
>
> By this point we should hopefully have a clearer picture.
>
> Mark



-- 
Dr RJ Bowles

25 Wellesley Avenue North  Norwich  NR1 4NT
+44 (0)7912 297662

Skype: bob.john.bowles
Email: bobjohnbowles@gmail.com

[2025-11-05-console_session.jpg (image/jpeg, attachment)]

---

Message #35 received at 920@bugs.devuan.org (full text, mbox, reply):

Hi Mark

Another follow-up you might find useful.

I have another rig running a clean install of Daedalus and I just
checked how /run/user/1000 was set up on there. User bob, group bob,
just like the one on the box exhibiting the bug.

It looks like part of the Excalibur upgrade should have changed the
group of /run/user/1000 from the owner to root, but this was missed.

Kind Regards   Bob Bowles

On Wed, 5 Nov 2025 at 17:16, Mark Hindley <mark@hindley.org.uk> wrote:
>
> Hi,
>
> [ Could you keep 920@bugs.devuan.org in the CC:, please? ]
>
> On Wed, Nov 05, 2025 at 04:59:41PM +0000, Bob Bowles wrote:
> > I did the following: login, did some random activity while monitoring
> > the memory, then left the terminal open monitoring memory at 16:03,
> > near as. Came back at 16:12 and watched while the system logged me
> > out. Then I went into console to check the logs, and found the last
> > entries in the user.log, timestamped 16:12:52. There is an error
> > message from pulseaudio. Could that be it?
>
> Possibly. Let's delve down that rabbit hole.
>
> Does /run exist? What are it's perms?
>
> $ ls -ld /run
> drwxr-xr-x 28 root root 1200 Nov  5 06:44 /run
>
> Is it mounted as a tmpfs?
>
> $ df -h /run
> Filesystem      Size  Used Avail Use% Mounted on
> tmpfs           392M  884K  391M   1% /run
>
> Does run/user/$USER exist and what are it's perms?
>
> $ ls -ld /run/user/$(id -u)
> drwx------ 10 mark root 320 Nov  5 16:29 /run/user/1000
>
> From the pulseaudio error you found, I think that may fail. If it fails, why?
> Have you got libpam-elogind installed?(I use seatd and consolekit, so I don't
> have the correct output to hand, but the following should produce something
> useful).
>
> $ dpkg -l libpam-elogind libelogind-compat
>
> Is elogind running?
>
> $ loginctl
>
> Is $XDG_RUNTIME_DIR set?
>
> $ echo $XDG_RUNTIME_DIR
> /run/user/1000
>
> By this point we should hopefully have a clearer picture.
>
> Mark



-- 
Dr RJ Bowles

25 Wellesley Avenue North  Norwich  NR1 4NT
+44 (0)7912 297662

Skype: bob.john.bowles
Email: bobjohnbowles@gmail.com

---

Message #40 received at 920@bugs.devuan.org (full text, mbox, reply):

Hi Mark

I have been experimenting with manually changing the group of /run/user/1000

Firstly, whatever manual changes are done, they are wiped every
reboot, so this isn't (as I thought earlier) explicitly to do with the
Excalibur upgrade. It seems that most packages in Excalibur expect the
owner/group to be user/root, but something still resets owner/group to
user/user during reboot.

If the group is changed to root after reboot but before gui login, I
notice several applications populate /run/user/1000 after gui login,
so it seems that this issue affects a lot more than just pulseaudio.
However, pulseaudio still fails and pulls down x11 with it, it just
doesn't complain about being able to access /run/user/1000/pulse.

It seems like there are actually two problems here:
1) the group identity of the directories in /run/user, where there
seems to be a mismatch in expectations between different parts of the
system. This seems to affect a lot of different packages, not just
pulseaudio.
2) other issues with pulseaudio that are making it fall over
ungracefully. This latter one is what causes the unwanted auto-logout.

I can post screenshots if required. but I think the description above
is clear enough. The system in question has no need of audio so I
could just remove pulseaudio, but that would not solve the underlying
issue(s).

Kind Regards   Bob Bowles

---

Message #45 received at 920@bugs.devuan.org (full text, mbox, reply):

Control: reassign -1 slim
Control: retitle -1 slim receives SIGTERM after period of inactivity

Bob,

We have managed to reproduce this and believe it is a problem with
slim. Hopefully rrq can debug further.

You might try changing to another display manager. Either xdm or wdm might be a
good choice for an older system. If that works around the issue for you, perhaps
you could confirm and it will at least make us certain we have identified the
right component.

Thanks

Mark

---

Message #54 received at 920@bugs.devuan.org (full text, mbox, reply):

Hi Mark

Pleased to hear you have made some progress.

I briefly tried switching to lightdm and xdm, with similar results.
Both logged errors indicating the xsession received a kill signal
after about 10 minutes of inactivity. In the case of lightdm it failed
to recover and left the computer with a blank screen with the only
options <Alt-SysReq>-B or hitting the power button. So for now I have
reconfigured slim, as the lesser of evils.

The big question is what is generating the SIGTERM?

Kind Regards  Bob

On Thu, 6 Nov 2025 at 18:39, Mark Hindley <mark@hindley.org.uk> wrote:
>
> Control: reassign -1 slim
> Control: retitle -1 slim receives SIGTERM after period of inactivity
>
> Bob,
>
> We have managed to reproduce this and believe it is a problem with
> slim. Hopefully rrq can debug further.
>
> You might try changing to another display manager. Either xdm or wdm might be a
> good choice for an older system. If that works around the issue for you, perhaps
> you could confirm and it will at least make us certain we have identified the
> right component.
>
> Thanks
>
> Mark



-- 
Dr RJ Bowles

25 Wellesley Avenue North  Norwich  NR1 4NT
+44 (0)7912 297662

Skype: bob.john.bowles
Email: bobjohnbowles@gmail.com

---

Message #59 received at 920@bugs.devuan.org (full text, mbox, reply):

OK, that appears to let slim off the hook.

I wonder what happens if you stop slim with

   sudo service slim stop


and run

  startx

from a tty?

If that also behaves badly, maybe ~/Xorg.0.log shows something.

Can you attach it? Screenshots are really too big.

Thanks

Mark

---

Message #64 received at 920@bugs.devuan.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

That was interesting. So here's what I did:
At slim login screen do console login
$ sudo service slim stop
$ startx (xfce starts up)
wait about 10 minutes

The result:
Around the 10-minute mark the screen went blank. Then I moved the
mouse, and the screen came back, just like a screensaver, Except I
don't have a screensaver (or didn't think I had...).
I checked ~/.xsession-errors, no errors
also Xorg.0.log, could not see anything obvious.

Please find attached the zipped logfile.

Thanks everyone for your help on this

Kind Regards  Bob

On Fri, 7 Nov 2025 at 09:04, Mark Hindley <mark@hindley.org.uk> wrote:
>
> OK, that appears to let slim off the hook.
>
> I wonder what happens if you stop slim with
>
>     sudo service slim stop
>
>
> and run
>
>    startx
>
> from a tty?
>
> If that also behaves badly, maybe ~/Xorg.0.log shows something.
>
> Can you attach it? Screenshots are really too big.
>
> Thanks
>
> Mark
>
>


-- 
Dr RJ Bowles

25 Wellesley Avenue North  Norwich  NR1 4NT
+44 (0)7912 297662

Skype: bob.john.bowles
Email: bobjohnbowles@gmail.com

[xorg.log.tar.gz (application/gzip, attachment)]

---

Message #69 received at 920@bugs.devuan.org (full text, mbox, reply):

Bob,

And what does the Xorg.log file contain when you use slim and it is killed? I
suspect it will be in /var/log/Xorg.0.log.

This is sounding a lot like Debian #1114853[1]. So, ultimately, Debian
libpciaccess bug #1111301[2].

Apparently only Intel i915 is affected. Bob, you said you have a 2005 Levono
Thinkcentre. What graphics does it have?

Mark

[1]  https://bugs.debian.org/1114853

[2]  https://bugs.debian.org/1111301

---

Message #74 received at 920@bugs.devuan.org (full text, mbox, reply):

I have not found anything in Xorg.0.log relating to the session death,
but I did find the information about the software part of the graphic,
which references the i915 you were talking about:
[  3218.650]    Module class: X.Org Video Driver
[  3218.650]    ABI class: X.Org Video Driver, version 25.2
[  3218.650] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
        i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
        915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
        Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
        GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[  3218.651] (II) intel: Driver for Intel(R) HD Graphics
[  3218.651] (II) intel: Driver for Intel(R) Iris(TM) Graphics
[  3218.651] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
[  3218.651] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  3218.651] (II) FBDEV: driver for framebuffer: fbdev
[  3218.651] (II) VESA: driver for VESA chipsets: vesa
[  3218.651] (II) intel(0): Using Kernel Mode Setting driver: i915,
version 1.6.0 0
[  3218.651] (II) intel(0): SNA compiled: xserver-xorg-video-intel
2:2.99.917+git20210115-1 (Timo Aaltonen <tjaalton@debian.org>)
[  3218.651] (II) intel(0): SNA compiled for use with valgrind
[  3218.652] (WW) Falling back to old probe method for modesetting
[  3218.652] (WW) Falling back to old probe method for fbdev
[  3218.652] (II) Loading sub module "fbdevhw"
[  3218.652] (II) LoadModule: "fbdevhw"
[  3218.652] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[  3218.653] (II) Module fbdevhw: vendor="X.Org Foundation"
[  3218.653]    compiled for 1.21.1.16, module version = 0.0.2
[  3218.653]    ABI class: X.Org Video Driver, version 25.2
[  3218.653] (--) intel(0): Integrated Graphics Chipset: Intel(R) 945G
[  3218.653] (--) intel(0): CPU: x86-64, sse2, sse3; using a maximum
of 1 threads


Message in ~/.xsession-errors when the session is killed more-or-less
as before, but no more complaints about /run/user/1000/pulse:
XIO:  fatal IO error 22 (Invalid argument) on X server ":0.0"
      after 13 requests (13 known processed) with 0 events remaining.
X connection to :0.0 broken (explicit kill or server shutdown).

The make and model of the chassis is Lenovo 8298-7BG manufactured in
2005 from parts inherited from IBM (IBM stamped on the chassis,
keyboard and motherboard)

The graphics hardware:
bob@ibm:~$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ
Integrated Graphics Controller (rev 02) hardware

On Fri, 7 Nov 2025 at 19:06, Mark Hindley <mark@hindley.org.uk> wrote:
>
> Bob,
>
> And what does the Xorg.log file contain when you use slim and it is killed? I
> suspect it will be in /var/log/Xorg.0.log.
>
> This is sounding a lot like Debian #1114853[1]. So, ultimately, Debian
> libpciaccess bug #1111301[2].
>
> Apparently only Intel i915 is affected. Bob, you said you have a 2005 Levono
> Thinkcentre. What graphics does it have?
>
> Mark
>
> [1]  https://bugs.debian.org/1114853
>
> [2]  https://bugs.debian.org/1111301
>


-- 
Dr RJ Bowles

25 Wellesley Avenue North  Norwich  NR1 4NT
+44 (0)7912 297662

Skype: bob.john.bowles
Email: bobjohnbowles@gmail.com

---

Message #79 received at 920@bugs.devuan.org (full text, mbox, reply):

Control: reassign -1 libpciaccess0
Control: tags -1 = debian
Control: retitle -1 xorg dpms activation causes server exit on i915
Control: forwarded -1 https://bugs.debian.org/1111301

Bob,

Thanks for the confirmation that you have i915 graphics. I am pretty sure we
have identified the issue.

For you, the immediate workaround should be to disable dpms.

If you require functioning dpms and want to add your voice to either of the
substantive Debian bugs requesting the suggested fixes are implemented, please do.

Best wishes

Mark

---

Message #92 received at 920@bugs.devuan.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Mark

The trick is to disable dpms without explicitly disabling it!

I have implemented the attached script in xfce4's Application
Autostart as a workaround, in case anyone is interested.

Thanks to everyone!

On Sat, 8 Nov 2025 at 08:42, Mark Hindley <mark@hindley.org.uk> wrote:
>
> Control: reassign -1 libpciaccess0
> Control: tags -1 = debian
> Control: retitle -1 xorg dpms activation causes server exit on i915
> Control: forwarded -1 https://bugs.debian.org/1111301
>
> Bob,
>
> Thanks for the confirmation that you have i915 graphics. I am pretty sure we
> have identified the issue.
>
> For you, the immediate workaround should be to disable dpms.
>
> If you require functioning dpms and want to add your voice to either of the
> substantive Debian bugs requesting the suggested fixes are implemented, please do.
>
> Best wishes
>
> Mark



-- 
Dr RJ Bowles

25 Wellesley Avenue North  Norwich  NR1 4NT
+44 (0)7912 297662

Skype: bob.john.bowles
Email: bobjohnbowles@gmail.com

[Bug920Workaround (application/octet-stream, attachment)]

---

Send a report that this bug log contains spam.

---