Hallo,
* Jamie Zawinski [Mon, Jan 11 2021, 01:13:10PM]:
> > my .icewm/startup file at the moment contains:
> >
> > xscreensaver -nosplash -log wtf-xscreensaver.txt &
> >
> > When icewm starts, I see the splash screen for a brief moment (not joking,
> > looks -nosplash has no effect there), but it
Am 11.01.21 um 22:04 schrieb Eduard Bloch:
Not sure which kind of backup you expect.
Well, you filed a serious bug report against systemd, so I expect at
least some kind of justification for that.
OpenPGP_signature
Description: OpenPGP digital signature
> my .icewm/startup file at the moment contains:
>
> xscreensaver -nosplash -log wtf-xscreensaver.txt &
>
> When icewm starts, I see the splash screen for a brief moment (not joking,
> looks -nosplash has no effect there), but it does not happen every time.
This kinda sounds like *something
Hallo,
* Michael Biebl [Sun, Jan 10 2021, 08:24:12PM]:
> Am 10.01.21 um 20:02 schrieb Jamie Zawinski:
> > > Why would a xscreensaver instance running for user A have any influence
> > > on a xscreensaver instance running for user B? That seems absolutely
> > > weird to me and something I don't
Am 10.01.21 um 20:02 schrieb Jamie Zawinski:
Why would a xscreensaver instance running for user A have any influence on a
xscreensaver instance running for user B? That seems absolutely weird to me and
something I don't understand.
Yeah, that sounds impossible, assuming that the X server has
> Why would a xscreensaver instance running for user A have any influence on a
> xscreensaver instance running for user B? That seems absolutely weird to me
> and something I don't understand.
Yeah, that sounds impossible, assuming that the X server has restarted between
user A and user B.
If
Am 10.01.21 um 18:48 schrieb Tormod Volden:
OK, so I guess removing the global user enablement will avoid having
xscreensaver running in lightdm. However, I still wonder if this
lingering service that was observed will also be the case if a user
logs out and another (or same) logs in within 15
OK, so I guess removing the global user enablement will avoid having
xscreensaver running in lightdm. However, I still wonder if this
lingering service that was observed will also be the case if a user
logs out and another (or same) logs in within 15 seconds? Is there
still an underlying issue
On Sun, Jan 10, 2021 at 5:46 PM Michael Biebl wrote:
> If you want to clean up this state, I would propose to use the following
>
> deb-systemd-helper --user purge xscreensaver.service >/dev/null || true
> deb-systemd-helper --user unmask xscreensaver.service >/dev/null || true
>
> Guarded by a
Hi Tormod
Am 10.01.21 um 15:12 schrieb Tormod Volden:
I should add that although we added the
debian/xscreensaver.user.service file in 5.44+dfsg1-2, we are using
"dh_installsystemduser --no-enable" since 5.45+dfsg1-1, so it won't be
enabled for the lightdm user in new installs or upgrades
On Jan 10, 2021, at 3:20 AM, Tormod Volden wrote:
>
> For a multi-user host the administrator expectations are different, since
> there might be various login managers and user desktop environments, and
> xscreensaver should only run in some of them.
I would think that if an administrator
I should add that although we added the
debian/xscreensaver.user.service file in 5.44+dfsg1-2, we are using
"dh_installsystemduser --no-enable" since 5.45+dfsg1-1, so it won't be
enabled for the lightdm user in new installs or upgrades skipping
5.44+dfsg1-2. It will now only be enabled for those
Am 10.01.21 um 13:19 schrieb Tormod Volden:
On Sun, Jan 10, 2021 at 12:44 PM Michael Biebl wrote:
Negating @system might work.
Something like ConditionUser=!@system, but untested.
Thanks! I was just about to suggest this myself after searching around for this.
On Sun, Jan 10, 2021 at 12:44 PM Michael Biebl wrote:
> Negating @system might work.
> Something like ConditionUser=!@system, but untested.
Thanks! I was just about to suggest this myself after searching around for this.
(https://www.freedesktop.org/software/systemd/man/systemd.unit.html)
I
Am 10.01.21 um 12:20 schrieb Tormod Volden:
On Fri, Jan 8, 2021 at 10:00 PM Jamie Zawinski wrote:
In xscreensaver (or maybe lightdm).
Why is xscreensaver started in the lightdm session anyway?
Is xscreensaver really usable as a per user service or should it be per session?
Why is the lightdm
On Fri, Jan 8, 2021 at 10:00 PM Jamie Zawinski wrote:
>
> > In xscreensaver (or maybe lightdm).
> > Why is xscreensaver started in the lightdm session anyway?
> > Is xscreensaver really usable as a per user service or should it be per
> > session?
> > Why is the lightdm xscreensaver instance
> In xscreensaver (or maybe lightdm).
> Why is xscreensaver started in the lightdm session anyway?
> Is xscreensaver really usable as a per user service or should it be per
> session?
> Why is the lightdm xscreensaver instance interfering with the xscreensaver
> instance of the logged in user?
>
Am 08.01.21 um 14:12 schrieb Eduard Bloch:
Hallo,
I don't fully agree. If you don't see a problem here, WHERE do you see
it?
In xscreensaver (or maybe lightdm).
Why is xscreensaver started in the lightdm session anyway?
Is xscreensaver really usable as a per user service or should it be per
Hallo,
I don't fully agree. If you don't see a problem here, WHERE do you see
it?
Under my naive assumptions, it looks like SIGTERM is not sent when
lightdm stops the service. So apparently a systemd issue.
I would like to investigate more but a there seems to be no "debug" or
"trace" mode for
Control: reassign -1 xscreensaver
I don't see a systemd problem here, so re-assigning to xscreensaver.
Am 08.01.21 um 13:04 schrieb Eduard Bloch:
Package: systemd
Version: 247.2-4
Severity: serious
Hi,
I am reporting this with high severity because it might affect system
security.
For
20 matches
Mail list logo
