Autokey restart cron

[tleish]

I still have problems with autokey not working after a while, so I
created a cron script to restart Autokey once an hour that isn't quite
working. I modified the script posted in:

http://groups.google.com/group/autokey-users/browse_thread/thread/e08eb626b8a34af9/30b236948c1129a5?lnk=gst&q=cron#30b236948c1129a5

The following script works perfect when I run it manually in a
terminal, but when run through a cron it stops autokey but is unable
to start it:
======SCRIPT=========
#!/bin/sh
#%%about=ak - Restart AutoKey
if [ ! "$1" = "" ]
then
echo "Usage: ak"
echo " Restarts Autokey"
exit
fi
killall -q autokey-gtk
sleep .3
killall -9 -q autokey-gtk
sleep .2
/usr/bin/autokey-gtk >/dev/null 2>&1 &
=================

If I remove ">/dev/null 2>&1 & " from the last line, I see in the logs
the following:

=======LOG===========
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57:
GtkWarning: could not open display
warnings.warn(str(e), _gtk.Warning)
/usr/lib/python2.7/dist-packages/autokey/interface.py:76: GtkWarning:
IA__gtk_clipboard_get_for_display: assertion `display != NULL' failed
self.clipBoard = gtk.Clipboard()
/usr/lib/python2.7/dist-packages/autokey/gtkapp.py:282: Warning:
invalid (NULL) pointer instance
message_format=message)
....
Floating point exception
==================

I'm guessting that somehow starting autokey outside of xserver is
causing a problem? Anyone have any suggestions or ideas?

[Joe]

On 12/14/2011 12:23 PM, tleish wrote:
> I still have problems with autokey not working after a while, so I
> created a cron script to restart Autokey once an hour that isn't quite
> working. I modified the script posted in:
>
> http://groups.google.com/group/autokey-users/browse_thread/thread/e08eb626b8a34af9/30b236948c1129a5?lnk=gst&q=cron#30b236948c1129a5
>
> The following script works perfect when I run it manually in a
> terminal, but when run through a cron it stops autokey but is unable
> to start it:
> ======SCRIPT=========
> #!/bin/sh
> #%%about=ak - Restart AutoKey
> if [ ! "$1" = "" ]
> then
> echo "Usage: ak"
> echo " Restarts Autokey"
> exit
> fi
> killall -q autokey-gtk
> sleep .3
> killall -9 -q autokey-gtk
> sleep .2
> /usr/bin/autokey-gtk>/dev/null 2>&1&
> =================
>

> If I remove ">/dev/null 2>&1& " from the last line, I see in the logs

> the following:
>
> =======LOG===========
> /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57:
> GtkWarning: could not open display
> warnings.warn(str(e), _gtk.Warning)
> /usr/lib/python2.7/dist-packages/autokey/interface.py:76: GtkWarning:
> IA__gtk_clipboard_get_for_display: assertion `display != NULL' failed
> self.clipBoard = gtk.Clipboard()
> /usr/lib/python2.7/dist-packages/autokey/gtkapp.py:282: Warning:
> invalid (NULL) pointer instance
> message_format=message)
> ....
> Floating point exception
> ==================
>
> I'm guessting that somehow starting autokey outside of xserver is
> causing a problem? Anyone have any suggestions or ideas?
>

Note: Only my last suggestion is likely to work. I'm including the rest
of this to show the thought process involved.

I think you're right. This looks like what happens when I login as root
and try to start a graphical application. The problem is that the root
account isn't set up for gui.
cron is a root process, so it's running your script as root. That's
part of the problem.

Another part is that cron runs background processes, not even associated
with a text console, so if it displays anything, that display
information has nowhere to go (/dev/null). You might be able to fix the
first problem by running your script as sudo -U <your-user>
<your-script> (maybe with a few other options), but that still wouldn't
fix the second problem of having nowhere to display things.

I think I ran into this when I had a brief dalliance with the
firestarter firewall. They got around it by having a daemon started by
cron and a separate gui interface to it that the user launched.

Running through all of this, I think part of the problem is that you're
using the wrong crontab. Instead of using the system-wide one for root,
you could add the event to your user's crontab (see: man at. You could
add this to your .profile script). That will get all the environment
stuff right (and there's no point in having it run when you're not even
logged on - as the system cron would do - and it could potentially
affect other users if, you have any). There's still the problem of it
being run in the "background", but there's probably a simple solution
for that. I haven't done much with at, so I'm not sure if/how it
handles foreground tasks.

I'm sure there's a better way, but, if all else fails, you could write a
script with an infinite loop and add that to your .profile. I think
that would overcome any obstacles.

#!/bin/bash
while 0
do
<your script from above>
sleep 1h
done

Joe

[Chris D]

I would hope that version 0.81.3 fixes the 'stop working after a
while' problem comprehensively - please let me know if it does not.

If you still need to do a periodic restart, you can use a tool called
gnome-schedule. It edits the user's crontab file and has the ability
to configure tasks that require a running X session (such as AutoKey).
Obviously you would still need to be logged in at the time the task
runs in order for it to work, but assuming that criterion is met, it
should work.

[Evan Edwards]

I think I posted a solution awhile back on this list. I have a
desktop file that launches autokey in a loop; launches, then waits for
it to end, then launches it again.

Then I have a script, ak. I can run it manually to kill autokey.
I can also add it to my crontab and kill it regularly, at which point
it is relaunched from within the context of the X server.

*** BAD SOLUTION FOLLOWS

A really nasty, non-suggested method is also to simply add the
following to the top of a script:

export DISPLAY=:0

This relies on Linux (and AIX and several other *nixes) and the
fact that on a single computer, you often only have one X desktop
active at any given time, and one user on the system. :0 is the first
allocated X session, so the above will set all X servers to attach to
the running X client (i.e., your desktop). It's pretty reliable in
practice, but if you depend on it, you'll find yourself in an odd
situation where that changes, and nothing will work correctly.

On the other hand, if Chris is about to fix the problem, this
might be an easy stopgap solution if you've already got a cron script
ready to go.

--
Evan Edwards
ev...@cheshirehall.net
814.889.8845

[tleish]

Thanks for all the suggestions. I just upgraded Autokey a few hours
ago to 0.81.3 and so far so good. Hopefully I won't need to finish
setting up a cron restart. I'll let you know.

[tleish]

I'm happy to report that I never needed to figure out a cron restart
script because the latest version of Autokey has been working for some
time now without a need to restart.

Thanks for the fix!

[Johnny Rosenberg]

2011/12/24 tleish <tle...@gmail.com>:

> I'm happy to report that I never needed to figure out a cron restart
> script because the latest version of Autokey has been working for some
> time now without a need to restart.
>
> Thanks for the fix!

That sounds great! Actually the latest version seems to be 0.81.4 now,
but I guess that doesn't necessarily mean that the bug is back… :P

I think I was the one who originally reported the problem and I must
say that I didn't have the problem at all the last months or so, but
the reason for that is maybe that I changed my routines slightly. I am
simply not sitting at my computer hour after hour these days…

Chris, it would be interesting (at least for me) to know what you did
to solve this problem and what was causing it. Maybe there is
information about it somewhere, I didn't search for it yet though.

Kind regards (and a happy Christmas for those of you who celebrate
things – well, of course I like everyone to be happy all the time :D)

Johnny Rosenberg
ジョニー・ローゼンバーグ