Arch Linux

Okay, it appears the only way to properly get my user to show up in who is to use a login manager that supports it. Even editing the proper sessreg commands into startx doesn't work.

This is a single-user machine, I'll just hard-code the proper locking command in. Sorry for the noise.

Doesn't seem to be consolekit's fault. I've found some people having similar problems with xdm and slim as login managers. Now I just need to figure out how to make startx deal with it.

Okay, I'm an idiot. I *do* have that directory, I just forgot to list hidden files. I stuck some debug points in the script and it appears it's not finding my user, on further examination because nothing for this display shows up in `who`. I think it might be consolekit's fault. I'll see if I can do some further debugging.

I just tested with startx, and, while the directory already existed, a socket was created for my session. I'm not sure what's actually creating the directory on my system.

I just use startx, with a couple arguments to wrap all of .xinitrc in a consolekit session.

@Celti - How do you start your X sessions? If it's with a login manager, which one?

This fails to work for me because I don't have a /tmp/.X11-unix/ directory. Anyone know what I can do to fix that?

@krisse7 - pm-utils-screen-lock-0.1.2-1 gets rid of the "return 0". It'll really only help if all sessions are using the same screen locker.

Just noticed one thing: is there a reason for the "return 0" in the script? Because now it locks only the first X session and leaves other possible sessions unlocked.

@krisse7 - pm-utils-screen-lock-0.1.1-1 now searches for gnome-screensav to deal with the 15 character limit.

@byronc - pgrep has the same 15 character limitation as ps, so either "pgrep gnome-screensav" or "pgrep -f gnome-screensaver". I now think that it would probably be better without the -f.

@krisse7 - I wonder if we actually need to use the -f with pgrep. I don't think any of the applications we actually detect (sans startkde) would break without it. pm-utils-screen-lock-0.1.0-1 removes the -f from all checks except for startkde.

Hmm... using pgrep -f solved one problem but now there is another: because the full command line is matched, getting a wrong match is much easier. (I happened to have a process with a command line argument "-nostop-xscreensaver", and so the script assumed I had xscreensaver running, although I don't even have it installed -> I ended up with an unlocked screen.) I don't know what would be the best solution, though...

@Raymond_Linux - pm-utils-screen-lock-0.0.9-1 now prints a message on first install with a list of packages that can be used as a screensaver.

Sorry for the late reply. Please add optional dependencies for a screensaver, and a message into the .Install file. Thanks again~

@krisse7 - Thanks for the report. pm-utils-screen-lock-0.0.8-1 should fix both issues.

Selecting gnome-screensaver does not work because "ps auxc" outputs only the first 15 characters of the process name. I fixed this by changing the line
elif ps auxc | grep gnome-[s]creensaver > /dev/null 2>&1; then
to
elif pgrep -f gnome-[s]creensaver > /dev/null 2>&1; then

I also noticed that using xlock does not work correctly; it locks the screen immediately and stops the suspending process until the screen is unlocked.

@Raymond_Linux - The goal of this package is to use whichever screensaver the user has installed. I'd rather not force the user to install an additional screensaver package in addition to the one they choose to use. For example: I use xautolock with xlock (from xlockmore) to handle screen locking and the package works fine without installing xscreensaver.

I would be willing to add optdepends for a screensaver or a message in a .install file. Any preference there?

Hi, I just installed it in Openbox with LXDE. I've found that it did not work and was wondering why. LXDE does not come with any screensaver settings by default. Hence, in addition to pm-utils, you'll also need xscreensaver installed in case there are none by default (to execute xscreensaver-command --lock, I suppose?). Once installed, I can execute "pm-suspend" and it'll lock the screen at the same time. Please add "xscreensaver" in the list of dependencies.

@macieks - good call. Version 0.0.7-1 operates as you suggest.

I suggest locking not on resume (events resume|thaw) from suspend but just before that (events hibernate|suspend ).

This way only screensaver will be visible after resume, now desktop is visible unless the screensaver starts.

Indeed that, your explanation makes perfect sense, thanks.

@b4283, those suggestions work great in the case that pm-{suspend,hibernate} is run directly by they user. The reason I check for the owner of the X session using who is so that I can run pm-suspend from acpid on lid events. In that situation, USER is root and the controlling TTY, if any, is also owned by root.

Just some suggestions, hope you take them because I think it's better. :)

Or, you can do it with checking the current TTYs, because the owner of the terminal (where you run `sudo pm-suspend') is always the same.

E.g.: USER=stat -c %U $(tty)

Hi, I just looked into the script today, and trying to figure out a better way to do it.

I find that any (sub)shell started with sudo has the ENVIRONMENT VARIABLES with a $SUDO_ prefix.
and $SUDO_USER ought to be useful in this package.

In case that $SUDO_USER doesn't exist, just use $USER instead, because it's mandatory to obtain root privilege to run pm-suspend. In this case, it's always root him/herself.