Arch Linux

cerino

Member

Registered: 2025-04-03

Posts: 10

[solved] systemd-inhibit as non-root systemd service

While trying to setup a systemd service with a restricted user, I came across the issue of not being able to use systemd-inhibit.
Instead the service fails with a message that interactive authentication is required, indicating missing permissions.

Normally systemd-inhibit is reserved for root and it would required something like a polkit rule to allow other users to use it, however it seems this rule already exist by default in arch (see /usr/share/polkit-1/actions/org.freedesktop.login1.policy) and indeed I can run "systemd-inhibit sleed 5" as a normal user, including the system user I setup for the systemd service.

The execution of systemd-inhibit only fails when it is used within systemd and I cant find any reason for this, especially since I can run the entire command, including systemd-inhibit within the service as the on the console as a non-root user.

[Unit]
Description=Backup Service

[Service]
Type=oneshot
User=mybackupuser
ExecStart=systemd-inhibit /usr/local/bin/rsync.sh

Update:
systemd-inhibit is bound to the logind session and not intended for use as a system service.

Last edited by cerino (2025-04-06 12:00:03)

jl2

Member

From: 47° 18' N 8° 34' E

Registered: 2022-06-01

Posts: 641

Website

Re: [solved] systemd-inhibit as non-root systemd service

https://superuser.com/questions/1413107 … thout-sudo

is the user in the wheel group? It might help

---

Why I run Arch? To "BTW I run Arch" the guy one grade younger.
And to let my siblings and cousins laugh at Arsch Linux...

cerino

Member

Registered: 2025-04-03

Posts: 10

Re: [solved] systemd-inhibit as non-root systemd service

https://superuser.com/questions/1413107 … thout-sudo

is the user in the wheel group? It might help

No, but why would that be necessary? Not only do I not want this user to be privileged, the user already can execute systemd-inhibit outside of systemd.
This seems more an issue with systemd then with missing permissions.

jl2

Member

From: 47° 18' N 8° 34' E

Registered: 2022-06-01

Posts: 641

Website

Re: [solved] systemd-inhibit as non-root systemd service

Did you even try any of the solutions suggested in or at least read the link I posted?

Because it clearly is mentioned multiple times that some types of systemd-inhibit do not work as a regular user.

I'm pretty sure your user (the one you tested it with) is in the sudo or the wheels group.
But if you don't wanna try, not my problem.

Last edited by jl2 (2025-04-04 10:14:13)

---

Why I run Arch? To "BTW I run Arch" the guy one grade younger.
And to let my siblings and cousins laugh at Arsch Linux...

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 24,244

Re: [solved] systemd-inhibit as non-root systemd service

systemd-inhibit acts on an active logind/dbus session, neither of which are given for a system wide service.

I'm smelling XY. Why do you want to do this from a system wide service, why  do you want to do this with a distinct user and why should said system wide service affect your own users session inhibition (I can piecemeal why you'd want to do this but I want to see/hear your thought process)

If it was me and this is primarily about backing up e.g. a $HOME I'd just do that as the normal user as part of a --user service or so.

As for the link posted, wheel was just the example, you can configure just that user to be allowed to invoke these and they'd generally fix this particular issue if you allow polkit for this specific user for these specific polkit actions.

Last edited by V1del (2025-04-04 13:11:32)

cerino

Member

Registered: 2025-04-03

Posts: 10

Re: [solved] systemd-inhibit as non-root systemd service

Did you even try any of the solutions suggested in or at least read the link I posted?

Because it clearly is mentioned multiple times that some types of systemd-inhibit do not work as a regular user.

Yes, I tried the solutions in the linked article even before posting here.
The systemd-inhibit do work as a regular user on arch, imho due to the default polkit settings. If you run

systemd-inhibit sleep 5

as a normal user in your terminal, do you get an error?

I'm pretty sure your user (the one you tested it with) is in the sudo or the wheels group.

No it is not, why would you assume so?
I tried with it added to the wheel group and it made no difference.

The error I get is also different from the linked page. It does not say "Access denied"
It returns: "Failed to inhibit: Interactive authentication required"

systemd-inhibit acts on an active logind/dbus session, neither of which are given for a system wide service.

I am not quite sure what this means. Is systemd-inhibit not the correct tool to prevent/postpone a system sutdown when running as a system service?

As for the link posted, wheel was just the example, you can configure just that user to be allowed to invoke these and they'd generally fix this particular issue if you allow polkit for this specific user for these specific polkit actions.

The user in question (as any user on the system)  can already execute systemd-inhibit when executed in a terminal, which is why I am so confused about the issue. Though Im beginnign to suspect it is related to the nature of systemd-inhibit and its intended use inside a logind session as you mentioned.

Why do you want to do this from a system wide service, why  do you want to do this with a distinct user and why should said system wide service affect your own users session inhibition (I can piecemeal why you'd want to do this but I want to see/hear your thought process)

If it was me and this is primarily about backing up e.g. a $HOME I'd just do that as the normal user as part of a --user service or so.

Running as a user service was what I used in the past, but there is a reason I want to change this.

The intention is as follows:

I want a system service for backups that runs as a different user to prevent those normal users to modify/delete their own backups. This works quite well even when using a restricted user if I add AmbientCapabilities=CAP_DAC_READ_SEARCH to allow reading other users files. Running this backup service with minimal privileges, while isolation the resulting backup files from their actual owners is one of the objectives. This all works as long as I do not use systemd-inhibit but since I want to run this on a timer, I need to prevent or rather postpone a shutdown sequence when the backup service happens to be running. The service usually only needs a few seconds but I would like to avoid it being interrupted if possible

jl2

Member

From: 47° 18' N 8° 34' E

Registered: 2022-06-01

Posts: 641

Website

Re: [solved] systemd-inhibit as non-root systemd service

I am not quite sure what this means. Is systemd-inhibit not the correct tool to prevent/postpone a system sutdown when running as a system service?

For shutdown, systemd invokes shutdown.target. Try something like this: https://askubuntu.com/questions/952363/ … n-shutdown

My bad, didn't read your post to the end.
just add a
Before=halt.target shutdown.target reboot.target
This should delay the targets. If that doesn't work, try Conflicts=, which should cancel the reboot.

Last edited by jl2 (2025-04-04 14:14:22)

---

Why I run Arch? To "BTW I run Arch" the guy one grade younger.
And to let my siblings and cousins laugh at Arsch Linux...

cerino

Member

Registered: 2025-04-03

Posts: 10

Re: [solved] systemd-inhibit as non-root systemd service

just add a
Before=halt.target shutdown.target reboot.target
This should delay the targets. If that doesn't work, try Conflicts=, which should cancel the reboot.

Unfortunately none of this had any effect.

here are the service files I tested:

[Unit]
Description=testA
Before=halt.target shutdown.target reboot.target

[Service]
Type=oneshot
ExecStart=sleep 600

[Install]
WantedBy=multi-user.target

[Unit]
Description=TestB
Conflicts=halt.target shutdown.target reboot.target

[Service]
Type=oneshot
ExecStart=sleep 600

[Install]
WantedBy=multi-user.target

When these are active and I enter /usr/bin/reboot into a terminal, the system reboots immediately

Last edited by cerino (2025-04-05 09:44:51)

jl2

Member

From: 47° 18' N 8° 34' E

Registered: 2022-06-01

Posts: 641

Website

Re: [solved] systemd-inhibit as non-root systemd service

https://superuser.com/questions/1450650 … own-reboot

Doesn't seem to work with user services, so try a systemd service with the User= flag like in the OP.

---

Why I run Arch? To "BTW I run Arch" the guy one grade younger.
And to let my siblings and cousins laugh at Arsch Linux...

cerino

Member

Registered: 2025-04-03

Posts: 10

Re: [solved] systemd-inhibit as non-root systemd service

https://superuser.com/questions/1450650 … own-reboot

Doesn't seem to work with user services, so try a systemd service with the User= flag like in the OP.

Didnt make any difference sadly.

cerino

Member

Registered: 2025-04-03

Posts: 10

Re: [solved] systemd-inhibit as non-root systemd service

Ok so apparently one option to get the intended result is to use ExecStop=mycommand in combination with ExecStart=true

This will postpone the shutdown completion until the commend is finished or the timeout is reached.

Can this really be the intended solution? It feels like a dirty hack but apparently thats how systemd wants it...

cerino

Member

Registered: 2025-04-03

Posts: 10

Re: [solved] systemd-inhibit as non-root systemd service

Since the systemd-inhibit is intended for user in a user session and not as a system service, I suppose this answers the question in this thread and I create a separate one to address the remaining issue.