Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #248120 > unrolled thread

(suspend && lock screen) vs (lock screen && suspend)

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  (suspend && lock screen) vs (lock screen && suspend) Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> - 2022-05-12 15:10 +0200
    Re: (suspend && lock screen) vs (lock screen && suspend) Greg Wooledge <greg@wooledge.org> - 2022-05-12 15:40 +0200
      Re: (suspend && lock screen) vs (lock screen && suspend) Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> - 2022-05-12 18:40 +0200
        Re: (suspend && lock screen) vs (lock screen && suspend) David Wright <deblis@lionunicorn.co.uk> - 2022-05-12 19:20 +0200
          Re: (suspend && lock screen) vs (lock screen && suspend) Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> - 2022-05-13 12:30 +0200

#248120 — (suspend && lock screen) vs (lock screen && suspend)

[Originally posted to comp.unix.shell but no replies there]

$ uname -a
Linux e130 5.16.0-0.bpo.4-amd64 #1 SMP PREEMPT Debian 5.16.12-1~bpo11+1 
(2022-03-08) x86_64 GNU/Linux
$ cat /etc/debian_version
11.2




Hi,

Not sure if this just a command invocation problem or there are other 
issues at hand (say, power management, etc) but... I have a script that 
binds to 'CTRL + SHIFT + S':


$ cat opt/bin/lock-suspend
#!/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?

-- 
Ottavio Caruso

[toc] | [next] | [standalone]

#248124

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.

[toc] | [prev] | [next] | [standalone]

#248134

On 12/05/2022 14:31, Greg Wooledge wrote:
> 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.


man 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.


man mate-screensaver-command

  -l, --lock
               Tells the running screensaver process to lock the screen 
immediately.


"race condition" or not, it doesn't  make sense that, upon resume, the 
screen lock pauses for 10 seconds and then reactivates.

-- 
Ottavio Caruso

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#248135

On Thu 12 May 2022 at 17:34:55 (+0100), Ottavio Caruso wrote:
> On 12/05/2022 14:31, Greg Wooledge wrote:
> > 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?

> "race condition" or not, it doesn't  make sense that, upon resume, the
> screen lock pauses for 10 seconds and then reactivates.

https://github.com/mate-desktop/mate-screensaver/issues/231

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248149

On 12/05/2022 18:10, David Wright wrote:
> On Thu 12 May 2022 at 17:34:55 (+0100), Ottavio Caruso wrote:
>> On 12/05/2022 14:31, Greg Wooledge wrote:
>>> 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?
> 
>> "race condition" or not, it doesn't  make sense that, upon resume, the
>> screen lock pauses for 10 seconds and then reactivates.
> 
> https://github.com/mate-desktop/mate-screensaver/issues/231

Thanks. Well spotted. However, I tried the workarounds suggested over 
there and it still delays a few seconds upon resume. It's definitely a 
Mate bug, then.


-- 
Ottavio Caruso

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web