Why systemctl suspend works but systemctl isolate suspend.target doesn't?

I mean: which is the internal difference between these two commands? I thought they were equivalent, but it is clear that they aren’t.

(moreover, systemctl isolate must be always executed as root while systemctl suspend doesn’t need to -if there’s only one open user session in system-. But that’s not important for me.)

Thanks a lot!

I do guess the main point is that what i marked with **>>. The Isolate UNIT gives no feedback while suspend does.

systemctl isolate UNIT

           IgnoreOnIsolate=yes (see systemd.unit(5)). If a unit name with no extension is given, an extension of
           ".target" will be assumed.
           **>>This command is dangerous, since it will immediately stop processes that are not enabled in the new
           target, possibly including the graphical environment or terminal you are currently using.

systemctl suspend

           Suspend the system. This will trigger activation of the special target unit suspend.target. This command
           is asynchronous, and will return after the suspend operation is successfully enqueued. It will not wait
           for the suspend/resume cycle to complete.

My assumption would be there’s a polkit rule in place for systemctl suspend, shutdown, reboot but not for systemctl isolate.

That’s probably the key part.

2 Likes

Aaah, I see…it seems the key is what you marked as **>> so I infer systemctl suspend does some sugar magic to solve this behaviour (but I don’t think it’s polkit…i can’t see the relation between an authorization framework and the killing of processes, @grumpey). Anyway, I’ll mark this answer as solved, though if anyone has more information, it will be wellcomed!
Thanks a lot all of you!

1 Like

The polkit rule would be the reason isolate requires authentication and suspend does not.

1 Like