Okay, so internally systemd is using CLOCK_MONOTONIC for the event
source that counts up to RuntimeMaxSec, and CLOCK_MONOTONIC does not
count the time when the system is suspended. Your use case wants
CLOCK_BOOTTIME, which does count time when the system is suspended. I
will work on a fix for
Thanks, that is very helpful. I tested this for service units too, and
got the same result:
$ systemd-run -u test-1.service -p RuntimeMaxSec=1m /usr/bin/bash -c 'while
true; do sleep 1; done'
$ systemctl suspend # Waited a bit...
After resume:
$ systemctl status test-1.service
● test-1.service
The session did eventually exit:
Active: failed (Result: timeout) since Fri 2023-04-21 11:24:31 PDT;
2min 48s ago
However, the time while the system was suspended didn't count towards
the session limit.
This kind of makes sense, but is also at odds with my goal of also using
pam_time to
ok, reproduced the failure - if the system is suspended at the session
expiry, the session apparently is never closed.
Active: active (running) since Fri 2023-04-21 11:13:02 PDT; 7min
ago
RuntimeMaxUSec=5min
--
You received this bug notification because you are a member of Ubuntu
Touch
Ah, now, rechecking, it appears the gdm session is mostly dead:
$ systemctl status session-35.scope --no-pager -l | sed -e's/User .*/User foo/'
× session-35.scope - Session 35 of User foo
Loaded: loaded (/run/systemd/transient/session-35.scope; transient)
Transient: yes
Active: failed
On Fri, Apr 21, 2023 at 03:57:58PM -, Nick Rosbrook wrote:
> Also, to check the active runtime, can you use `systemctl show
> --property=ActiveEnterTimestamp session-X.scope`? Or just show the full
> output of systemctl status session-X.scope. It should inform us if it is
> counting up to
Also, to check the active runtime, can you use `systemctl show
--property=ActiveEnterTimestamp session-X.scope`? Or just show the full
output of systemctl status session-X.scope. It should inform us if it is
counting up to RuntimeMaxSec.
--
You received this bug notification because you are a
Okay. I'm curious what the output is when RuntimeMaxSec does not seem to
be enforced. Does this fail consistently again or is it irregular?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
On Mon, Apr 17, 2023 at 01:30:11PM -, Nick Rosbrook wrote:
> Odd. Does `systemctl show --propoerty=RuntimeMaxUSec session-2.scope`
> show the same thing, or something different?
For a current session, which is session-93.scope, I see in the file:
RuntimeMaxSec=1h 38min 56s
And from
Odd. Does `systemctl show --propoerty=RuntimeMaxUSec session-2.scope`
show the same thing, or something different?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2015126
Although this was working with the ppa package, enforcement is failing
again.
# apt policy systemd
systemd:
Installed: 249.11-0ubuntu3.10~debug1
Candidate: 249.11-0ubuntu3.10~debug1
Version table:
*** 249.11-0ubuntu3.10~debug1 500
500
Thanks for testing!
** Also affects: systemd (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Kinetic)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu Jammy)
Status: New => Triaged
** Changed in: systemd (Ubuntu
Thanks, I've confirmed the fix on jammy here.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2015126
Title:
systemd doesn't successfully enforce RuntimeMaxSec for gnome
Jammy version with my fix is in ppa:enr0n/systemd-249.
** Changed in: systemd (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2015126
Er, I built and tested on kinetic, but I can build the fix for jammy
too.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2015126
Title:
systemd doesn't successfully
I was able to re-produce this in a different way, but I'm pretty sure
it's the same bug that affects you. For scope units in particular, the
RuntimeMaxSec property is not applied correctly when systemd is
reloaded. E.g., if I run:
$ systemd-run --scope -u foo-1.scope /usr/bin/foo
$ mkdir -p
For reference, populating RuntimeMaxSec is done via
https://github.com/vorlonofportland/pam_session_timelimit; there is no
existing support for this in Ubuntu today.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in
17 matches
Mail list logo
