[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (suspend && lock screen) vs (lock screen && suspend)



On Thu, May 12, 2022 at 02:06:24PM +0100, Ottavio Caruso wrote:
> #!/bin/sh
> systemctl suspend && mate-screensaver-command  -l

> This one seems to work, however I would have thought that the logical
> sequence would be:
> 
> mate-screensaver-command  -l && systemctl suspend
> 
> that is, a) lock screen; b) suspend; c) resume with lock screen on.
> 
> Instead, if I use the latter syntax, upon resuming, there is a 10 second
> delay before locking the screen, which is not ideal for obvious privacy
> reasons.
> 
> Any input on that?

Any analysis here would require some knowledge of what each of these
commands actually *does*.  I know nothing about mate-screensaver-command,
so I can only focus on systemctl.

Normally, the systemctl command either requests information from systemd
and writes it to stdout (or pipes it into a pager), *or* it sends an
action request to systemd.

I'm not a laptop guy, and I've never suspended anything, and I don't
really understand the basic concepts of that.  But "systemctl suspend"
sounds like the sort of command that sends an action request to systemd,
and then terminates without waiting for systemd to actually do its thing.
That's how commands like "systemctl restart servicename" work.

So, in your script (the one that works), you first run a command that
requests an action from systemd and terminates immediately after sending
the request; and then, if it returns a successful exit status, you run
the mate-screensaver-command.  Meanwhile, systemd is presumably doing
this "suspend" thing at the same time as mate-screensaver-command is
doing whatever it does.

To me this sounds like a classic race condition.  Two things are going
at the same time, and the end result depends on which one finishes first.
But without knowing the full details of how these two things actually
work, I can't say much more.


Reply to: