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:

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

  • 1
    I do not see how it can run successfully: cron job do not see the DISPLAY variable, by default, and do not have the required authorization to access the X server. – enzotib Aug 22 '11 at 20:32
  • First of all: Why would you want to do that? It seems that you are trying to achieve something that can be dome in more proper way. – rozcietrzewiacz Aug 22 '11 at 20:52
  • I turned off the logoff confirmation message so when it runs it will just logout. I changed /etc/gdm/PostSession/Default to add in some custom code to emulate a nuke and restore of the user's home directory on logout. – Mechaflash Aug 22 '11 at 21:03
  • @rozcietrzewiacz how would you go about scheduling this command to run? – Mechaflash Aug 22 '11 at 21:12
  • 2
    From gnome-session-save manpage: You can specify the --kill argument to terminate the GNOME session. Why on earth would you want to do this periodically? – rozcietrzewiacz Aug 22 '11 at 22:13

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.

  • This is the only feasible reason why it's not working. – Mechaflash 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 linuxquestions.org/linux/answers/Applications_GUI_Multimedia/… 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. – Mechaflash 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? – Mechaflash Aug 23 '11 at 13:18
  • 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

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


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

  • 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 >>>>>> – Mechaflash 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. – Mechaflash Aug 24 '11 at 13:51

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

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


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

*/15 22-23,00-05 * * * gui-cron gnome-session-quit --power-off
  • 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 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

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.

  • 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. – Mechaflash Aug 22 '11 at 21:08
  • /var/log/syslog even shows the job running and it didn't return any errors =/ – Mechaflash 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. – Mechaflash Aug 22 '11 at 21:42
  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.