1. Forum
  2. Usenet
  3. COMP.UNIX.SHELL

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

    From Ottavio Caruso@21:1/5 to All on Wed May 11 15:16:00 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Kempe@21:1/5 to All on Fri Jun 10 17:41:47 2022
    Den 2022-05-11 skrev Ottavio Caruso <[email protected]>:
    Hi,


    Hello,

    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:


    I have to agree with you that the sequence of first locking and then
    suspending seems the reasonable one so you have me intrigued.

    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?


    A quick glance at the source code shows that mate-screensaver can be
    built with systemd support. It then listens for the PrepareForSleep
    signal sent by systemd and does a few things. It appears that it could
    be configured to lock the screen automatically on suspend. If I were
    to guess, the signal sent by systemctl suspend conflicts with your mate-screensave-command -l call in some way.

    To figure out what's going on, I would suggest enabling debug logging
    for mate-screensaver and/or using dbus-monitor to see what messages it
    sends and receives.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ottavio Caruso@21:1/5 to Andreas Kempe on Sat Jun 11 11:10:41 2022
    On 10/06/2022 18:41, Andreas Kempe wrote:
    Den 2022-05-11 skrev Ottavio Caruso <[email protected]>:
    Hi,


    Hello,

    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:


    I have to agree with you that the sequence of first locking and then suspending seems the reasonable one so you have me intrigued.

    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?


    A quick glance at the source code shows that mate-screensaver can be
    built with systemd support. It then listens for the PrepareForSleep
    signal sent by systemd and does a few things. It appears that it could
    be configured to lock the screen automatically on suspend. If I were
    to guess, the signal sent by systemctl suspend conflicts with your mate-screensave-command -l call in some way.

    To figure out what's going on, I would suggest enabling debug logging
    for mate-screensaver and/or using dbus-monitor to see what messages it
    sends and receives.



    In any case, it looks mate-* on Debian Bullseye is quite old and
    bug-ridden. I have added the testing repos and upgraded mate-* (possibly
    fixing something and breaking even more) and we'll take it from there.

    --
    Ottavio Caruso

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)