On 2017-12-03 18:40:03, Daniel Kahn Gillmor wrote: > On Mon 2017-12-04 00:14:05 +0100, Tormod Volden wrote: >> I am not so into systemd "units", but possibly relevant to your >> question is that it is fully possible that the xscreensaver package is >> installed on a system, but that individual users don't want to have it >> running. Whether it should start by default for a user depends on the >> desktop environment. > > I think if xscreensaver is installed, it should be enabled by default. > desktop environments that don't want it enabled can explicitly disable > it for users which launch them, as can users who for whatever reason > want it disabled.
I think it was explicitely disabled because of this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977804 > Most systems won't have xscreensaver installed at all unless the user > has requested it, right? I think that's not the point - in the above, the systemd activation conflicted with the xsession one. Also: it didn't work, for me. In Debian buster, xscreensaver tried to start before Xorg was available, and failed to contact the DISPLAY (server). In bullseye, however, this unit works: [Unit] Description=XScreenSaver Documentation=man:xscreensaver(1) Documentation=man:xscreensaver-command(1) Documentation=man:xscreensaver-demo(1) PartOf=graphical-session.target [Service] ExecStart=/usr/bin/xscreensaver Restart=on-failure [Install] WantedBy=default.target I suspect that this is the part that doesn't work in buster: PartOf=graphical-session.target Also notice this trick: Restart=on-failure Which should prevent some security issues from unlocking the screen by crashing it. It's not quite complete: it should also *lock* the screen on crash, but it's a start. -- It is not enough to fight for the land; it is even more important to enjoy it. While you can. While it’s still here. - Edward Abbey
