0

I am trying to issue the gnome-session-save --kill command via crontab. I used the command sudo crontab -e. In the file is this:

PATH=/usr/bin
00 00 * * * gnome-session-save --kill

The command does not run as it is supposed to. /var/log/syslog shows it running successfully however.

In the command I've also tried the full path to the command (/usr/bin/gnome-session-save --kill) without any luck either.

Ubuntu 10.04LTS

Caleb
  • 70,105
Anthony Miller
  • 1,257

4 Answers4

3

First, you should not be using sudo crontab -e for this. That will edit the crontab file for the root user. You need this to run in your user crontab so that the gnome session that gets saved is yours. Drop the sudo and just run crontab -e. If necessary add yourself to the cron.allow file so that you are allowed to have a crontab file as your user. (Also remember to edit root's crontab again and remove that entry.)

Secondly you can't run things like gnome utilities from cron without hooking them up with the correct $DISPLAY variables. The environment that cron passes on to it's children is not nearly as complete as a login shell and since it doesn't run inside your graphical login environment, it isn't wired up to it. Consider this: it's possible to have more than one graphical environment running. How would a system script know which one you want to operate on? It doesn't. You need to figure out the what DISPLAY it's running on and pass that to your command.

Lastly, this seems like ALL the wrong place to be doing this anyway. Why on earth would you want to periodically kill a session? Anything the user is doing at that momment is going to be nuked. Also cron runs whether or not the user is logged in, so it may not even always have anything to operate on.

Caleb
  • 70,105
  • This is the only feasible reason why it's not working. – Anthony Miller Aug 23 '11 at 13:07
  • We're setting up this machine as a computer for workers to jump on periodically on their breaks to surf, facebook, twitter... anything within reason. However, we don't want them permanently storing files to the hard drive. I've used this script http://www.linuxquestions.org/linux/answers/Applications_GUI_Multimedia/Deepfreeze_for_Linux to do a nuke&restore on the machine, added it to /etc/gdm/PostSession/Default file, and with this question I'm trying to make it so the machine auto-logs off at 6pm everyday to clear our the guest's folder and restoring it to our default. – Anthony Miller Aug 23 '11 at 13:11
  • 1
    Your first employee working overtime past 6pm will --kill you. How about running something in the session itself that triggers a logoff on inactivity? – Caleb Aug 23 '11 at 13:14
  • However... tell me this... if i throw that command in a shell script and run it manually... it works without fail. But cron won't run the shell script? – Anthony Miller Aug 23 '11 at 13:18
  • even what you ask for seems impossible. There's a way to lock the workstation but not logout the user when idle for a period of time. I believe it pertains to the same issue I'm having – Anthony Miller Aug 23 '11 at 13:23
  • 1
    @Mechaflash: See the second paragraph of my answer. Any shell you open up from inside the graphical environment has things like the $DISPLAY variable set to connect it to that environment. In a sense they are "children" of that session, so the gnome-session-save command knows exactly what session to operate on: it's parent. Things run from cron are not launched from inside your login environment. You would have to find and explicitly kill the the session yourself. – Caleb Aug 23 '11 at 13:23
  • I give you 1 million ups. See answer and it works flawlessly. – Anthony Miller Aug 23 '11 at 13:32
  • Also, the employee working overtime past 6pm will get killed by their dept. manager if they catch them here past 6pm on a breakroom computer =P – Anthony Miller Aug 23 '11 at 13:45
0

Caleb was right about passing the correct display variable. I also used crontab -e instead of SUDOing it. In Ubuntu, all you would have to do is specify which display to pass in Crontab. So my command looks like this:

00 18 * * * env DISPLAY=:0 gnome-session-save --kill

the env DISPLAY=:0 is what tells to pass the cronjob to the current display (desktop). Alternatively, if you have multiple displays, you can specify which display to pass to using a decimal (0.0 = display 1, 0.1=display 2 etc.)

http://webcache.googleusercontent.com/search?q=cache:jdM1kg3ituMJ:https://help.ubuntu.com/community/CronHowto+https://help.ubuntu.com/community/CronHowto%23GUI%2520Applications&cd=1&hl=en&ct=clnk&gl=us&source=www.google.com

Yes I used the google web cache cause the page wasn't loading correctly for me =D.

Anthony Miller
  • 1,257
  • And to get the record straight. This machine is a breakroom machine for users to jump on during their breaks to surf the web etc. I have a Windows equivalent "Deep Freeze" script that runs when the machine logs out. The command gnome-session-save --kill is just a generic way of logging out the user. If you type it in your terminal it will even bring up a log out confirmation. I use gconf-editor and remove the log out confirmation so it will just log out instead of showing me the prompt. Continued below >>>>>> – Anthony Miller Aug 24 '11 at 13:49
  • I changed the login to auto-login the user when the computer is booted. When editing the /etc/gdm/PostSession/Default file, I added in the deep freeze script and before the exit 0, threw in /sbin/restart gdm so the script will automatically log back in the user after logout. – Anthony Miller Aug 24 '11 at 13:51
0

As Pavel Selivanov points out in this article it is necessary to set DBUS_SESSION_BUS_ADDRESS and DISPLAY to enable gui related tasks from a cronjob.

He has written a shell script, which gets the DBUS_SESSION_BUS_ADDRESS for XFCE, Gnome, Unity, Cinnamon and KDE. I can confirm that is works under ubuntu:16.04.

$ sudo nano /usr/local/bin/gui-cron

#!/bin/sh
[ "$#" -lt 1 ] && echo "Usage: $0 program options" && exit 1

program="$1"
shift

user=$(whoami)
env_reference_process=$( pgrep -u "$user" xfce4-session || pgrep -u "$user" cinnamon-session || pgrep -u "$user" gnome-session || pgrep -u "$user" gnome-shell || pgrep -u "$user" kdeinit )

export DBUS_SESSION_BUS_ADDRESS=$(cat /proc/"$env_reference_process"/environ | grep -z ^DBUS_SESSION_BUS_ADDRESS= | sed 's/DBUS_SESSION_BUS_ADDRESS=//')
export DISPLAY=$(cat /proc/"$env_reference_process"/environ | grep -z ^DISPLAY= | sed 's/DISPLAY=//')
"$program" "$@"

Then one can create a user cronjob that runs by a given schedule with the crontab syntax. Here e.g. every 15 minutes between 22:00 and 05:59:

$ crontab -e

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
*/15 22-23,00-05 * * * gui-cron gnome-session-quit --power-off
swiesend
  • 111
  • You misspelled "cinnamon" throughout. This has no hope of working in its current form; even with that fixed, this probably solves the wrong problem in the first place. – tripleee Jun 18 '17 at 14:24
  • tripleee thanks for the hint with the misspelling. I only tested it with success under ubuntu:16.04 with Unity, don't know about the otherpgreps. – swiesend Jun 18 '17 at 14:33
  • I am curios @tripleee how would you solve the problem instead? – swiesend Jun 18 '17 at 14:38
  • It would be easier and more straightforward to run a background job from the Gnome session manager itself; that way, you avoid stupid failures when no one is logged in, and automatically get authorization to manipulate the user's session. – tripleee Jun 18 '17 at 14:41
  • Would it be possible to schedule such a background job? – swiesend Jun 18 '17 at 14:46
  • I'd go for a simple while true; do stuff; sleep 300; done – tripleee Jun 18 '17 at 16:21
  • .. Unless there is a simple way to just remove or disable the session saving functionality within Gnome itself. – tripleee Jun 18 '17 at 16:24
-1

I have seen a similar kind of error. If you put just that command in a shell script, and then just add that shell script to cron, it will work. Create something like killGnome.sh

#!/bin/sh
gnome-session-save --kill

Make sure you give the above execute permissions. And then in your crontab add this:

00 00 * * * /path/to/killGnome.sh

I am not sure why though. :| Edits welcome.

Sudipta Chatterjee
  • 619
  • Did not work. I tried the full path in the .sh file as well. And also adding in PATH=/usr/bin for the crontab file. – Anthony Miller Aug 22 '11 at 21:08
  • /var/log/syslog even shows the job running and it didn't return any errors =/ – Anthony Miller Aug 22 '11 at 21:09
  • Very crude idea - but you could potentially capture the pid using grep and issue a kill -9 to that. This isn't recommended as a permanent solution, though. – Sudipta Chatterjee Aug 22 '11 at 21:12
  • Well... in theory this IS what the command does... I will try it and see if there are any adverse effects. If it works then it works. I don't really care at this point in time lol. – Anthony Miller Aug 22 '11 at 21:42
  • Do vote the answer up if this does work! :) – Sudipta Chatterjee Aug 22 '11 at 22:47
  • Failure. No vote for you =P – Anthony Miller Aug 23 '11 at 13:06
  • @SudiptaChatterjee: Just killing the processes would work, but it's much easier to do with pkill gnome-session. As root you could also kill -u $user to just nuke everything that was running as the user account in question. – Caleb Aug 23 '11 at 13:38
  • 1
    As for your main answer, in general that should have no effect. You must have done something funky with your rc files so that even a non-login shell gets some things in shouldn't. The environment cron ran the command in is the same one that is passed to the script, so this is a net zero effect unless your invoking /bin/sh does something out of the ordinary. – Caleb Aug 23 '11 at 13:40