Bug#978589: systemd based startup not working
Hallo, I have created a new bug report for the issue of xscreensaver not being properly terminated: http://bugs.debian.org/979562 The issue with xscreensaver-systemd persists. It seems like either when xscreensaver is killed by SIGTERM or it's aborted because another one is active, there is a process like this remaining in the background forever: xscreensaver-systemd -verbose Best regards, Eduard.
Bug#978589: systemd based startup not working
Hallo, * Eduard Bloch [Sat, Jan 02 2021, 11:52:50AM]: > Hallo, > * Jamie Zawinski [Wed, Dec 30 2020, 07:05:29PM]: > > > created. With absolute path, it is created but then it's created by > > > lightdm user first and then maybe the user session cannot replace it. > > > > Ok, that definitely means you're running as the wrong user, which explains > > why .Xauthority is not readable. Though why the earlier xscreensaver log > > said you were running as the correct user is confusing. Unless that log was > > from before this problem began. > > I don't have enough information to judge here. What I see is that the > xscreensvaer logo appears twice, i.e. when the lightdm screen comes and > when the xsession starts. When I check on the process list briefly in > those first seconds, there is: > > lightdm 4881 0.2 0.0 18924 5936 ?Ss 11:44 0:00 \_ > xscreensaver > lightdm 4959 0.0 0.0 5716 1064 ?SN 11:44 0:00 | \_ > xscreensaver-systemd > > So not running as user. And that process is terminated soon. And what > happened with the second appearence of the logo? This looks like an > aborted start of xscreensaver. > > Is this maybe lightdm failing to stop its instance in time so > xscreensaver cannot attach the the session and silently dies? > > Maybe should be a question to Debian maintainers of resp. stakeholders. > > > > Ok. Is this supposed to be gone when user logs out? Does this interfere > > > with my trying different parameters (-log, --log, etc.) above, are those > > > cached and therefore ignored after subsequent changes? So I switched to another DM, gdm3 instead of lightdm. And rebootet. gdm3 does not use xscreensaver, IIRC. Result: xscreensaver still not starting, nor is there a xscreensaver-systemd process. But there is: Debian-+7672 0.0 0.0 232856 6072 tty1 Sl+ 11:54 0:00 | \_ /usr/libexec/gsd-screensaver-proxy Which also terminates within the first minute. And like before, systemctl --user status xscreensaver.service only shows the logs which failed due to inaccessible DISPLAY and cookie problems. But that status also never changes. I can logout, and login again, there is no additonal attempt to start the user service. I can run systemctl --user restart xscreensaver.service manually and then it starts, and on logout it is reported as failed Active: failed (Result: exit-code) since Sat 2021-01-02 12:10:58 CET; 14s > Process: 6435 ExecStart=xscreensaver (code=exited, status=1/FAILURE) (obviously: xscreensaver[6435]: X connection to :0 broken) But it is NEVER RESTARTED. I think it should be answered by Debian maintainers and I don't know whom to ask: - how is the DISPLAY environment for systemd user session supposed to get there? - why are failed services not restarted when user logs out / logs in? For now, I will run in from .xsession again. systemd integration is just buggy. Best regards, Eduard.
Bug#978589: systemd based startup not working
On Jan 2, 2021, at 2:52 AM, Eduard Bloch wrote: > > I don't have enough information to judge here. What I see is that the > xscreensvaer logo appears twice, i.e. when the lightdm screen comes and > when the xsession starts. When I check on the process list briefly in > those first seconds, there is: Ok, that's different! You mean the splash screen? If you're seeing that, then it did manage to connect to the X server! This is all very strange, I'm not sure what's going on. I guess I'd try to coerce more logs out of everything involved? -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978589: systemd based startup not working
Hallo, * Jamie Zawinski [Wed, Dec 30 2020, 07:05:29PM]: > > created. With absolute path, it is created but then it's created by > > lightdm user first and then maybe the user session cannot replace it. > > Ok, that definitely means you're running as the wrong user, which explains > why .Xauthority is not readable. Though why the earlier xscreensaver log said > you were running as the correct user is confusing. Unless that log was from > before this problem began. I don't have enough information to judge here. What I see is that the xscreensvaer logo appears twice, i.e. when the lightdm screen comes and when the xsession starts. When I check on the process list briefly in those first seconds, there is: lightdm 4881 0.2 0.0 18924 5936 ?Ss 11:44 0:00 \_ xscreensaver lightdm 4959 0.0 0.0 5716 1064 ?SN 11:44 0:00 | \_ xscreensaver-systemd So not running as user. And that process is terminated soon. And what happened with the second appearence of the logo? This looks like an aborted start of xscreensaver. Is this maybe lightdm failing to stop its instance in time so xscreensaver cannot attach the the session and silently dies? Maybe should be a question to Debian maintainers of resp. stakeholders. > > Ok. Is this supposed to be gone when user logs out? Does this interfere > > with my trying different parameters (-log, --log, etc.) above, are those > > cached and therefore ignored after subsequent changes? > > xscreensaver-systemd should be killed by xscreensaver when it exits, but it's > definitely not a part of the problem that you're experiencing right now. Right now I cannot reproduce it, but I am almost sure that I have seen it once. xscreensaver-systemd was haning around without associated xscreensaver process. > > ## > > xscreensaver: 19:08:25: logging to "/tmp/xscreensaver-log.txt" at Wed Dec > > 30 19:08:25 2020 > > ## > > No "running as" line in this log? I've pasted the whole file. Best regards, Eduard. -- alphascorpii: channel.d.d/fortunes.html Rhonda: Die Seite mag ich nicht, da bin ich so häufig drauf.
Bug#978589: systemd based startup not working
> created. With absolute path, it is created but then it's created by > lightdm user first and then maybe the user session cannot replace it. Ok, that definitely means you're running as the wrong user, which explains why .Xauthority is not readable. Though why the earlier xscreensaver log said you were running as the correct user is confusing. Unless that log was from before this problem began. > Ok. Is this supposed to be gone when user logs out? Does this interfere > with my trying different parameters (-log, --log, etc.) above, are those > cached and therefore ignored after subsequent changes? xscreensaver-systemd should be killed by xscreensaver when it exits, but it's definitely not a part of the problem that you're experiencing right now. > ## > xscreensaver: 19:08:25: logging to "/tmp/xscreensaver-log.txt" at Wed Dec 30 > 19:08:25 2020 > ## No "running as" line in this log? > Just guessing, is this maybe some bug of xscreensaver-systemd which > makes it request an early shutdown of xscreensaver? No, all "xscreensaver-systemd" does is occasionally run "xscreensaver-command". You are not getting that far. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978589: systemd based startup not working
Hallo, * Jamie Zawinski [Tue, Dec 29 2020, 04:48:10PM]: > > Once logged in, I can see some active process of xscreensaver (this is what > > "pidof xscreensaver" tells me). > > > > But after some seconds, this process is gone. Why? Don't know. > > Dunno. Maybe it's trying to connect and timing out. Run xscreensaver with > --log log.txt I tried, but no such file gets created, even with absolute path. After RTFM and some time wasted I guess that it should be -log AND NOT --log. And then, when I use it with relative path, no such file is created. With absolute path, it is created but then it's created by lightdm user first and then maybe the user session cannot replace it. I could trick my way around it by removing the file manually, though. After some daemon-reload runs, I cannot even start it now whatsoever. Means: journalctl or "systemctl --user status xscreensaver.service" show me the last log lines from an hour ago (with the failed-to-open-DISPLAY issue). systemctl --user status | grep saver -> nothing However without --user: CGroup: / ├─user.slice │ └─user-500.slice │ ├─user@500.service │ │ ├─app.slice │ │ │ ├─pulseaudio.service │ │ │ │ └─12150 /usr/bin/pulseaudio --daemonize=no ... │ │ └─init.scope │ │ ├─2483 /lib/systemd/systemd --user │ │ └─2484 (sd-pam) │ ├─session-2.scope │ │ └─2748 xscreensaver-systemd ... The PID of xscreensaver-systemd does not fit, it's an old process, started an hour ago. /proc/2748 confirms it, this belong to the old lines in "systemctl --user status". But I did close and restart the X session severtal times now, why is that process not dead? > Or if you have an old version, -verbose -no-capture -log log.txt That said, I saw something odd, sometimes xscreensaver was started. That made me remember something, I think I had a similar problem on this same system some months ago and it did not work with systemd but I took a shortcut due to lag of time and so I have put it into the startup file of the window manager. And it seems like it had worked this way since then. So my previous statement was not fully correct. Nevertheless, the systemd way does not work even after I removed the custom startup call. > > 2884 0.0 0.0 5716 1064 ?SN 01:13 0:00 xscreensaver-systemd > > > > The manpage of this binary is slightly confusing. That is some kind of > > helper, fine, but who is supposed to run it? Xsession? Or systemd user > > session? It mentions "When run from ~/.xsession or equivalent" but there > > is no information on what is considered "equivalent" here. > > It is launched by xscreenasver itself. Ok. Is this supposed to be gone when user logs out? Does this interfere with my trying different parameters (-log, --log, etc.) above, are those cached and therefore ignored after subsequent changes? Anyway, I killed it now, logged out, logged in, the process is not coming back, and the picture looks like above (old status log in the "systemctl --user status" output). Also, xscreensaver process was running for some seconds and then disappeared. However, this time it created a log file. ## xscreensaver: 19:08:25: logging to "/tmp/xscreensaver-log.txt" at Wed Dec 30 19:08:25 2020 ## xscreensaver: 19:08:26: running on display ":0.0" xscreensaver: 19:08:26: vendor is The X.Org Foundation, 1201. xscreensaver: 19:08:26: useful extensions: xscreensaver: 19:08:26: MIT Screen-Saver (disabled at compile time) xscreensaver: 19:08:26: Shared Memory (1.2) xscreensaver: 19:08:26: Double-Buffering (1.0) xscreensaver: 19:08:26: Power Management (1.2) xscreensaver: 19:08:26: GLX xscreensaver: 19:08:26: XF86 Video-Mode (2.2) xscreensaver: 19:08:26: XC Misc (disabled at compile time) xscreensaver: 19:08:26: Xinerama (1.1) xscreensaver: 19:08:26: Resize-and-Rotate (1.5) xscreensaver: 19:08:26: XInput xscreensaver: 19:08:26: libsystemd xscreensaver: 19:08:26: screen 0 non-colormapped depths: 24. xscreensaver: 19:08:26: WARNING: RANDR and Xinerama report different xscreensaver: 19:08:26: screen layouts! Believing RANDR. xscreensaver: 19:08:26: screens in use: 1 xscreensaver: 19:08:26:3/0: 1920x1080+0+0 (HDMI-1) xscreensaver: 19:08:26: rejected screens: 4 xscreensaver: 19:08:26:0/0: 1920x1080+0+0 (DVI-D-1) -- output disabled xscreensaver: 19:08:26:1/0: 1920x1080+0+0 (DP-1) -- output disabled xscreensaver: 19:08:26:2/0: 1920x1080+0+0 (DP-2) -- output disabled xscreensaver: 19:08:26:4/0: 1920x1080+0+0 (HDMI-2) -- output disabled xscreensaver: 19:08:26: selecting RANDR events xscreensaver: 19:08:26: not using XInputExtension. xscreensaver: 19:08:26: consulting /proc/interrupts for keyboard activity. xscreensaver: 19:08:26: 0: visual 0x21 (
Bug#978589: systemd based startup not working
> Once logged in, I can see some active process of xscreensaver (this is what > "pidof xscreensaver" tells me). > > But after some seconds, this process is gone. Why? Don't know. Dunno. Maybe it's trying to connect and timing out. Run xscreensaver with --log log.txt Or if you have an old version, -verbose -no-capture -log log.txt > 2884 0.0 0.0 5716 1064 ?SN 01:13 0:00 xscreensaver-systemd > > The manpage of this binary is slightly confusing. That is some kind of > helper, fine, but who is supposed to run it? Xsession? Or systemd user > session? It mentions "When run from ~/.xsession or equivalent" but there > is no information on what is considered "equivalent" here. It is launched by xscreenasver itself. > Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Service has > more than one ExecStart= setting, which is only allowed for Type=oneshot > services. Refusing. > Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Cannot add > dependency job, ignoring: Unit xscreensaver.service has a bad unit file > setting. Sounds like it doesn't like your edits? -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978589: systemd based startup not working
Hallo, * Jamie Zawinski [Mon, Dec 28 2020, 06:07:55PM]: > The fact that $DISPLAY is not set at the time xscreensaver is launched is not > a good sign. The cookie error suggests that ~/.Xauthority does not exist or > is not readable. However you do appear to be running as yourself, not as > "nobody". Perhaps $HOME is set to something weird? Maybe try setting your > command to "printenv ; pwd ; xdpyinfo ; xscreensaver" and see if that > provides some clues. > No, nothing special I am aware of. Symptoms are very strange. Once logged in, I can see some active process of xscreensaver (this is what "pidof xscreensaver" tells me). But after some seconds, this process is gone. Why? Don't know. And I see another process, what is this? 2884 0.0 0.0 5716 1064 ?SN 01:13 0:00 xscreensaver-systemd The manpage of this binary is slightly confusing. That is some kind of helper, fine, but who is supposed to run it? Xsession? Or systemd user session? It mentions "When run from ~/.xsession or equivalent" but there is no information on what is considered "equivalent" here. Anyway, I patched /usr/lib/systemd/user/xscreensaver.service to add your instructions: $ cat /usr/lib/systemd/user/xscreensaver.service [Unit] Description=XScreenSaver [Service] #ExecStart=xscreensaver ExecStart=/bin/sh -c "printenv ; pwd ; xdpyinfo ; xscreensaver" [Install] WantedBy=default.target I did daemon-reload (for --user). Net result: no visible change but the state is this now: $ systemctl --user status xscreensaver.service ● xscreensaver.service - XScreenSaver Loaded: loaded (/usr/lib/systemd/user/xscreensaver.service; enabled; vendor preset: enabled) Active: inactive (dead) Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing. Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Cannot add dependency job, ignoring: Unit xscreensaver.service has a bad unit file setting. Now this does not make any sense anymore. Best regards, Eduard.
Bug#978589: systemd based startup not working
The fact that $DISPLAY is not set at the time xscreensaver is launched is not a good sign. The cookie error suggests that ~/.Xauthority does not exist or is not readable. However you do appear to be running as yourself, not as "nobody". Perhaps $HOME is set to something weird? Maybe try setting your command to "printenv ; pwd ; xdpyinfo ; xscreensaver" and see if that provides some clues.
Bug#978589: systemd based startup not working
Package: xscreensaver Version: 5.45+dfsg1-1 Severity: important Hi, just what the title says. I have configured xscreensaver start via systemd user session as suggested in README.Debian. Not working now but it has been a few weeks ago. I am wondering about the MAGIC COOKIE problem. My startup sequence is old school, lightdm -> Xsession and ~/.xsession contains a few commands and eventually "exec icewm-session". One noteworthy thing is also that for a few seconds after login I can see an active xscreensaver process in the process list and then it suddenly terminates. $ systemctl --user status xscreensaver.service â—? xscreensaver.service - XScreenSaver Loaded: loaded (/usr/lib/systemd/user/xscreensaver.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2020-12-29 00:30:47 CET; 7min ago Process: 2652 ExecStart=xscreensaver (code=exited, status=1/FAILURE) Main PID: 2652 (code=exited, status=1/FAILURE) CPU: 6ms Dez 29 00:30:47 whitestar xscreensaver[2652]: xscreensaver: 00:30:47: warning: $DISPLAY is not set: defaulting to ":0.0". Dez 29 00:30:47 whitestar xscreensaver[2652]: Invalid MIT-MAGIC-COOKIE-1 keyxscreensaver: 00:30:47: Can't open display: :0.0 Dez 29 00:30:47 whitestar xscreensaver[2652]: xscreensaver: 00:30:47: running as bloch/bloch (500/500) Dez 29 00:30:47 whitestar xscreensaver[2652]: xscreensaver: 00:30:47: Errors at startup are usually authorization problems. Dez 29 00:30:47 whitestar xscreensaver[2652]: But you're not logging in as root (good!) so something Dez 29 00:30:47 whitestar xscreensaver[2652]: else must be wrong. Did you read the manual and the FAQ? Dez 29 00:30:47 whitestar xscreensaver[2652]: https://www.jwz.org/xscreensaver/faq.html Dez 29 00:30:47 whitestar xscreensaver[2652]: https://www.jwz.org/xscreensaver/man.html Dez 29 00:30:47 whitestar systemd[2626]: xscreensaver.service: Main process exited, code=exited, status=1/FAILURE Dez 29 00:30:47 whitestar systemd[2626]: xscreensaver.service: Failed with result 'exit-code'. Best regards, Eduard. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.1+ (SMP w/12 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers 1.60 ii libatk1.0-0 2.36.0-2 ii libc62.31-6 ii libcrypt11:4.4.17-1 ii libglib2.0-0 2.66.4-1 ii libgtk2.0-0 2.24.32-5 ii libpam0g 1.4.0-1 ii libpango-1.0-0 1.46.2-3 ii libsystemd0 247.2-3 ii libx11-6 2:1.6.12-1 ii libxext6 2:1.3.3-1.1 ii libxi6 2:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxml2 2.9.10+dfsg-6.3+b1 ii libxmu6 2:1.1.2-2+b3 ii libxrandr2 2:1.5.1-1 ii libxt6 1:1.2.0-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.45+dfsg1-1 Versions of packages xscreensaver recommends: pn libjpeg-turbo-progs ii perl 5.32.0-6 ii wamerican [wordlist] 2019.10.06-1 ii wngerman [wordlist] 20161207-8 ii xfonts-100dpi 1:1.0.4+nmu1 Versions of packages xscreensaver suggests: ii chromium [www-browser] 87.0.4280.88-0.3 ii elinks [www-browser] 0.13.2-1+b1 ii falkon [www-browser] 3.1.0+dfsg1-9 ii firefox [www-browser]84.0-3 ii fortune-mod [fortune]1:1.99.1-7.1 ii gdm3 3.38.2.1-1 ii lynx [www-browser] 2.9.0dev.6-1 pn qcam | streamer ii w3m [www-browser]0.5.3-38+b1 pn xdaliclock pn xfishtank pn xscreensaver-data-extra pn xscreensaver-gl pn xscreensaver-gl-extra -- no debconf information -- hm... kann man eigentlich auch von vorne poppen oder nur von hinten? -- Wo kann man eigentlich Verbesserungen für die Fortunes anbringen? cpt_nemo: Geschichtsfälscher!
