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

Improve this question
10
  • 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. Commented Aug 22, 2011 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. Commented Aug 22, 2011 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. Commented Aug 22, 2011 at 21:03
  • @rozcietrzewiacz how would you go about scheduling this command to run? Commented Aug 22, 2011 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? Commented Aug 22, 2011 at 22:13

4 Answers 4

Reset to default
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.

Improve this answer
8
  • This is the only feasible reason why it's not working. Commented Aug 23, 2011 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. Commented Aug 23, 2011 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? Commented Aug 23, 2011 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? Commented Aug 23, 2011 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. Commented Aug 23, 2011 at 13:23
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.

Improve this answer
2
  • 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 >>>>>> Commented Aug 24, 2011 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. Commented Aug 24, 2011 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" -x xfce4-session || pgrep -u "$user" -x cinnamon-session || pgrep -u "$user" -o gnome-session || pgrep -u "$user" -x gnome-shell || pgrep -u "$user" -x 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
Improve this answer
8
  • 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. Commented Jun 18, 2017 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. Commented Jun 18, 2017 at 14:33
  • I am curios @tripleee how would you solve the problem instead? Commented Jun 18, 2017 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. Commented Jun 18, 2017 at 14:41
  • Would it be possible to schedule such a background job? Commented Jun 18, 2017 at 14:46
-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.

Improve this answer
8
  • 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. Commented Aug 22, 2011 at 21:08
  • /var/log/syslog even shows the job running and it didn't return any errors =/ Commented Aug 22, 2011 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. Commented Aug 22, 2011 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. Commented Aug 22, 2011 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. Commented Aug 23, 2011 at 13:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.