WM quits (or gets killed) when idle for long

[mbert]

My machine is on 24/7. In the evening I lock the screen (xscreensaver), unlock again on the next morning. Sometimes I don't use the machine for a few days.

After having switched back to WM with the recent new release I have run into this issue: when switching on the display in the morning I am at the GDM login prompt, and my session has ended.

I ran an strace -p on all WM processes the other day. No crash, segfault etc., the process ended peacefully. In syslog I cannot see any hint either.

Having switched to another window manager again, I am not seeing this issue.

Something's wrong here. It looks like WM after some while just performs a controlled logout.

[crmafra]

On Wed, 27 Sep 2023 at 1:07:55 -0700, Martin Dietze wrote: My machine is on 24/7. In the evening I lock the screen (xscreensaver), unlock again on the next morning. Sometimes I don't use the machine for a few days. After having switched back to WM with the recent new release I have run into this issue: when switching on the display in the morning I am at the GDM login prompt, and my session has ended. I ran an `strace -p` on all WM processes the other day. No crash, segfault etc., the process ended peacefully. In syslog I cannot see any hint either. Having switched to another window manager again, I am not seeing this issue. Something's wrong here. It looks like WM after some while just performs a controlled logout.

Is there any pattern in how long it takes to logout?

[mbert]

When I am away over the weekend it always does. I think, but I am not sure, that over night it does, too. I'll have to check today (and attach the processes to strace again).

[mbert]

Last night was enough to trigger the problem. I have created a full set of strace logs for WM and its parent processes.

The wmaker process has two direct children: ssh-agent and wmaker --for-real. According to the strace output it receives a SIGCHLD, hence one of the two children must have terminated.

Now the wmaker --for-real process performs one thing I find rather difficult to understand:

close(0)                                = 0
kill(1595759, SIGKILL)                  = 0
newfstatat(AT_FDCWD, "/home/user/GNUstep/Defaults", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
umask(077)                              = 022
openat(AT_FDCWD, "/home/user/GNUstep/Defaults/WMState.KN1WPs", O_RDWR|O_CREAT|O_EXCL, 0600) = 0
umask(022)                              = 077
fchmod(0, 0644)                         = 0
fcntl(0, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
newfstatat(0, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0
write(0, "{\n  Dock = {\n    AutoRaiseLower "..., 4096) = 4096
write(0, "reensaver-demo.Xscreensaver-demo"..., 4096) = 4096
write(0, "           Forced = No;\n        "..., 4096) = 4096
write(0, "bin/qtcreator\";\n            Omni"..., 4096) = 4096
fsync(0)                                = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=1595759, si_uid=1791805878, si_status=SIGKILL, si_utime=55 /* 0.55 s */, si_stime=11 /* 0.11 s */} ---
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], NULL, 8) = 0
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGKILL}], WNOHANG, NULL) = 1595759
wait4(-1, 0x7fff2048666c, WNOHANG, NULL) = 0
rt_sigprocmask(SIG_UNBLOCK, ~[RTMIN RT_1], NULL, 8) = 0
rt_sigreturn({mask=[]})                 = 0
write(0, " Omnipresent = No;\n          },\n"..., 1853) = 1853
close(0)                                = 0
rename("/home/user/GNUstep/Defaults/WMState.KN1WPs", "/home/user/GNUstep/Defaults/WMState") = 0
kill(1595759, SIGTERM)                  = -1 ESRCH (No such process)
poll([{fd=0, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=0, revents=POLLNVAL}])
exit_group(0)                           = ?
+++ exited with 0 +++

It terminates child process 1595759 via SIGKILL. This child process had been created long before:

pipe2([5, 6], 0)                        = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7efef86f6bd0) = 1308726
close(5)                                = 0
fcntl(6, F_SETFD, FD_CLOEXEC)           = 0

Of course we don't know what program the cloned process then ran, and this is by far not the only call to clone in the log. However, as we see in the first log snippet, after the child process is killed, WM seems to shut down.

While WM was idle (and I away) my screen was protected by xscreensaver-command -lock. It is by the way the same command I have used for locking with other window managers.

I will keep my strace logs for now, so if you have any further question, send me an email (you should still have my address).

[mbert]

Another observation. May be related. I am using xscreensaver for locking my screen (by the way, a native WM screen locker would be very nice to have). This morning, after having been locked over the weekend I found WM still running, but xscreensaver (running in random mode, with 3d animations enabled), while still locking the screen looked "transparent" on one of my monitors, i.e. showed what was underneath. After unlocking the screen I found that xscreensaver animations were still shown as desktop background, not the images I have configured. There was no way to get rid of this behaviour until I logged out and then back in.

[crmafra]

On Mon, 9 Oct 2023 at 2:10:37 -0700, Martin Dietze wrote: Another observation. May be related. I am using xscreensaver for locking my screen (by the way, a native WM screen locker would be very nice to have). This morning, after having been locked over the weekend I found WM still running, but xscreensaver (running in random mode, with 3d animations enabled), while still locking the screen looked "transparent" on one of my monitors, i.e. showed what was underneath. After unlocking the screen I found that xscreensaver animations were still shown as desktop background, not the images I have configured. There was no way to get rid of this behaviour until I logged out and then back in.

Would it be possible to use another screensaver like xlock? It could be some bad interaction between wmaker and the screensaver, it would be good if we could nail it down. Does anyone else see a behavior like this? Please send me a "me too" reply if so. I sometimes let wmaker running under a screensaver (xlock) but never experienced these logouts. Do you ever sleep to RAM on this machine?

[mbert]

Would it be possible to use another screensaver like xlock? It could be some bad interaction between wmaker and the screensaver, it would be good if we could nail it down.

Sure, I will give it a try.

Do you ever sleep to RAM on this machine?

No. Workstation, used as a server from remote when not at my desk.

[mbert]

Back at my desk today. Funny effect: when switching the displays on, I see my (xlock) lock screen. Without me doing anything, it "flickers", shows my WM desktop, then my lock screen again. I switch the displays off and then on again, and I am back at my login screen, WM has quit.

[gryf]

What type of connection are you using for the displays?

[mbert]

What type of connection are you using for the displays?

2 displays via display port.

[gryf]

I used to have similar issues with my desktop, which I've sometimes leaved up and running during the night. It wasn't something which happen every time (but often enough to annoy me), when I found it up with the console screen, instead of wmaker. I didn't even found anything useful in the logs and getting towards of thinking, that it might be connected with the xorg drivers, not wmaker, or there is something fishy going on between X and window manager, like forcing resolution, or whatever.

Also I mildly remember, that wmaker without display detected by Xorg was loosing dockapps or messing up their position, as when X didn't recognize/detect any connected displays it sets some minimal resolution for screen, like:

$ DISPLAY=:0 xrandr 
Screen 0: minimum 320 x 200, current 320 x 200, maximum 16384 x 16384
HDMI-1 disconnected primary (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-3 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)

wmaker processes are up and running, and the only thing I can see on .xsession-errors is:

CRITICAL: [    randr_update:0142] Get monitors reported 0 monitors. Falling back to single monitor mode.

and even, if I connect the display, I'll never get into wmaker, probably because my monitor doesn't support resolution 320x200.

So here's the thing. My setup was AMD based (CPU + RX570 PCI card), and I've used display port to connect the displays. If you have HDMI output on your graphics card and HDMI socket on one of the monitors, try to connect it with HDMI instead of DP, and see what happens.

I know that's only a workaround (and, I'm kind of forced to use one display connected with DP and the other with HDMI, as my new tiny PC have only one of each connector type), but it might help to narrow down the issue. Perhaps there is something done extra for the X server, when displays are connected using only the DP connectors.

[mbert]

Thank you. One more thing: I switch the monitors off when away. That may leave to monitors no longer being detected.

[gryf]

When Xorg starts with initially connected monitors, it will start the wmaker just fine, and even, if you turn displays later off, it shouldn't do anything. I didn't noticed that simply turning monitor off affects wmaker, but when displays go off caused by DPMS it sometimes cause wmaker/xorg process to exit.

[sashaaaaaaaaa]

Another observation. May be related. I am using xscreensaver for locking my screen (by the way, a native WM screen locker would be very nice to have). This morning, after having been locked over the weekend I found WM still running, but xscreensaver (running in random mode, with 3d animations enabled), while still locking the screen looked "transparent" on one of my monitors, i.e. showed what was underneath. After unlocking the screen I found that xscreensaver animations were still shown as desktop background, not the images I have configured. There was no way to get rid of this behaviour until I logged out and then back in.

yeah this sounds similar to what i reported #34, except the screensaver doesn't still run after unlocking.