[SOLVED] Can't get any cron job to work!

micxz · 07-29-2009, 01:15 AM

OK. Now I got it working. No more xhost.
Now I'm going to try and figure out how to write to my girlfriends screen...

soupnsandwich · 07-29-2009, 12:21 PM

Quote:

OK. Now I got it working. No more xhost.
Now I'm going to try and figure out how to write to my girlfriends screen...

What do ya mean? What are you trying to do?
soup

Micxz...I got to regroup with this problem. You guys have help me a lot...but I think I have to reread this topic and run through everything again. No global cron will work. Cron only works when the "crontab" command setup the cron job for root or a user. Why is it everything I read about cron is nothing more than placing ANY script in the /etc/cron.hourly/daily/weekly/monthly folders and it should work?! Has anybody actually got that to work like that?
It doesn't seem like anybody that did get that to work actually exists for a conversation.

I was hoping that I could offer Kcron to the end user to schdule user cron job, but so far it's waaaay to complicated for that.

Ok pressing on to see if I can get this resolved.

Just for kicks I tryed "at" job scheduler and of course it works great...to bad it will only run one time and get auto deleted?

Any suggestions?

Soup

catkin · 07-29-2009, 12:51 PM

Hello Soup

Quote:

Originally Posted by soupnsandwich

Cron only works when the "crontab" command setup the cron job for root or a user. Why is it everything I read about cron is nothing more than placing ANY script in the /etc/cron.hourly/daily/weekly/monthly folders and it should work?! Has anybody actually got that to work like that?
It doesn't seem like anybody that did get that to work actually exists for a conversation.

Sorry -- I only ever used cron via individual user crontabs, never via the /etc/cron.hourly/daily/weekly/monthly folders. I guess that applies to most people or you'd be having that conversation.

I respect your desire to explore every avenue and make things work in the way you first found; by persisting with that you will become very knowledgeable. Or you will get very side-tracked and take ages to do what you set out to do!

In cases like these, I go with what works and make a note of the question. Mostly those questions get answered sooner or later, I get things done quickly and I still end up learning a lot

.

Best

Charles

soupnsandwich · 07-29-2009, 01:00 PM

Ok...some progress.

I made the script that cron is trying to run very very simple.

Code:

#!/bin/bash
echo DISPLAY=$DISPLAY >> /tmp/log.$$
kcalc
echo "do something is done" >> /tmp/log.$$

Now this is suppose to run the calculator app.
I first tested this as root running the command "crontab -e".

The crontab was about as simple as it get also.

Code:

* * * * * /usr/bin/debug > /dev/null

Now the log file showed up in /tmp/log...so it ran the job...but kcalc didn't open. Now I'm sure I got this to work before after you guys told me to add the "DISPLAY:0.0" to the script, and add the "> /dev/null" to the crontab entry, but it doesn't seem to want to run the command and open kcalc...I'm not sure why. But at least I got a log file indicated that it ran.

I then removed that cronjob using "crontab -r"
I copied the contents (one line) of the previous crontab entry and edited the existing crontab file in /etc/crontab. I removed everything in that file except the line I just copied (

Code:

* * * * * /usr/bin/debug > /dev/null

). I restarted crond with "service -f crond" and waited for that minute to pass. When it did..nothing happend. No log was created and no command was run.
So as I expected the global cron jobs in /etc/ doesn't seem to work. Now "crond" is running in the processes.

Is there possibly a different cron(d) daemon for global jobs verses user/root cron jobs??

soup

soupnsandwich · 07-29-2009, 01:40 PM

Quote:

Sorry -- I only ever used cron via individual user crontabs, never via the /etc/cron.hourly/daily/weekly/monthly folders. I guess that applies to most people or you'd be having that conversation.

I respect your desire to explore every avenue and make things work in the way you first found; by persisting with that you will become very knowledgeable. Or you will get very side-tracked and take ages to do what you set out to do!

In cases like these, I go with what works and make a note of the question. Mostly those questions get answered sooner or later, I get things done quickly and I still end up learning a lot .

Best

Charles

Ahh thanks very much for your reply. I have a way around every issue that I have had along the way so far...it's just means reinventing the wheel though!

It's very true that the more persistent you are the more you learn. I'm sure that's the case with most of us here. I have to say that I have my strong points...and cron/bash isn't one of them

. I appreciate your input on this and your time.

If I can't get this to work before release time my work around will be a mandatory prompt for the user to select their user name from a drop down list and I'll work some magic changing a default crontab in /var/spool/cron to their own user name..and restarting the service. Of course it's a bit more complex then that...but if I have to do it I will.

Thanks Charles,
Chris (soup)

catkin · 07-29-2009, 01:40 PM

Hello Soup

Quote:

Originally Posted by soupnsandwich;3624515I copied the contents (one line) of the previous crontab entry and edited the existing crontab file in /etc/crontab. I removed everything in that file except the line I just copied ([CODE

* * * * * /usr/bin/debug > /dev/null[/CODE])
[snip]
Is there possibly a different cron(d) daemon for global jobs verses user/root cron jobs??

No, but there's a different format for lines in the /etc/crontab file; the 6th field is the user name (else how will cron know which user to run the command as?) and the rest of the line is the comand as usual. On ununtu 8.04 this is exampled (not explained) in the crontab man page in the section on "EXAMPLE SYSTEM CRON FILE". The same probably goes for crontabs in the /etc/cron.{daily,weekly,monthly,d} directories.

Best

Charles

soupnsandwich · 07-29-2009, 02:15 PM

Interesting...ok something else to check out.

THanks
Soup

jschiwal · 07-29-2009, 07:13 PM

Maybe the form "local:root" wasn't so bad as I first thought.
Most people who use xhost would just have "xhost +root" or even worse "xhost +".

But the target allowed would still be any user using the xserver. You could have more than one user, and more than one display controlled by an xserver. AFAIK, the xhost command would allow access to all the displays and all the users. For thin client environments, xhost would probably not be acceptable, and you would probably make a few admins very mad. Not all customers will be using their own workstation. Some workstations might be multi-seated.

Code:

export DISPLAY=:0.0

You might want to obtain the PID of the gnome, kde or xfce session and then get the DISPLAY variable from it's environment.
tr '\0' '\n' </proc/$pid/environ | grep DISPLAY

The DISPLAY variable is most likely :0.0, but consider a user who uses the second interface in a dual head card. The DISPLAY would be :0.1 in that case. Someone who logs in via ssh would have a DISPLAY like ":10.0" or "11.0".

The USER variable would also be part of the environment. You need that for the xauth command.

Could you post your final script. I would find it very instructive!

Cheers!

micxz · 07-29-2009, 07:57 PM

Soup have you put the simple /usr/bin/debug script in cron hourly and seen results (try without a X program)? I think cron is working fine as mentioned before you need to follow the correct formatting for the /etc/crontab file if used. For your testing I would stick to users individual crontabs.

Cron is one thing but your issues with graphical programs running to any users screen is another. There is a program called xauth. The xauth program is used to edit and display the authorization information used in connecting to the X server. Check out "man xauth"

On my system my screen auth file or magic-cookie is already imported to root when I open a root terminal. Try "xauth list" to view the cookies. In addition to having the cookie imported to the user/process that is trying to display graphical programs to your screen you need to know what $DISPLAY they are on.

So in conclusion you need to find out who is running a windows manager import their mit-magic-cookie and find out their $DISPLAY set it in your environment then run a x program.

That being said I was able to sent stuff to users display using this script cron or not:

Code:

#!/bin/bash

# Get users display magic cookie add it and notify them
# Need to be ROOT

#get users logged in with X
user=`ps waux | grep kdeinit | awk '{print $1}' | sort | uniq | grep -v root`
echo user=$user;

for i in $user; do
cookie=`su - -c "xauth list" $i | grep unix | sort | uniq`
xauth add $cookie
dis=`echo $cookie | awk '{print $1}' | awk -F: '{print $2}'`
export DISPLAY=:$dis.0
#/usr/bin/xeyes&
notify-send -t 100000 -u low -i gtk-dialog-info "Test" "Hello" || exit 0 
done;

Now this only works if user are running kde hence the first real line "ps waux | grep kdeinit....." I'm working on a way to get all user running any type of windows manager but this is of course just me just playing around and version .01 lol

micxz · 07-29-2009, 08:03 PM

Quote:

Originally Posted by jschiwal

Maybe the form "local:root" wasn't so bad as I first thought.
Most people who use xhost would just have "xhost +root" or even worse "xhost +".

I thought so but I decided to not use it at all. Thanks for the heads up.

Quote:

Originally Posted by jschiwal

You might want to obtain the PID of the gnome, kde or xfce session and then get the DISPLAY variable from it's environment.
tr '\0' '\n' </proc/$pid/environ | grep DISPLAY

I tried this already but I get:

Code:

cat /proc/19192/environ | grep DISPLAY
Binary file (standard input) matches

It looks to be on one line so you would have to other means to get it the value out of environ

$DISPLAY for users logged in via ssh now you got me thinking!

jschiwal · 07-29-2009, 08:11 PM

The environmental variables in /proc/<pid>/environ are separated with NUL characters. You can easily translate them to newlines using the tr program: tr '\0' '\n' /proc/$pid/environ | grep DISPLAY

micxz · 07-29-2009, 08:22 PM

Quote:

Originally Posted by jschiwal

The environmental variables in /proc/<pid>/environ are separated with NUL characters. You can easily translate them to newlines using the tr program: tr '\0' '\n' /proc/$pid/environ | grep DISPLAY

Awesome this is what I needed. the example you posted I get "tr: extra operand `/proc/19192/environ'"
But:
cat /proc/19192/environ | tr '\0' '\n' | grep DISPLAY
WORKS! jschiwal you've done it again!

soupnsandwich · 07-29-2009, 09:42 PM

Wow guys...awesome...but I'm not on the same level here with this stuff as you guys are. Some of this stuff that you guys were talking about was a bit over my head, but I do have some good test results.

First yes I did use the debugging script and cron is for sure working correctly. Just as an added test I added a command that plays a sound from /usr/share/sounds/ I placed that command with the debugging part of the script and it worked! I logged on as a different normal user and the sound played on time and the debug sent a log file to /tmp/.... So cron is definitly working. THanks for the debugging script.

So I added the "play /usr/share/sounds/KDE_Dialog_Appear.ogg" command to my existing "Notify" script and added that to /etc/cron.hourly. I modified the times in crontab file so that the scipt ran every minute just so I wouldn't have to wait for the whole hour to pass. Well the script ran because the sound played...but of course the rest of the script didn't run. Now I do have at the top of that script the "DISPLAY:0.0" command...but the no pop up notification are seen on any session, root or normal user...but the sound is played.

So now is the part I'm kind of lost on. I'm not sure that I follow what you guys were talking about to resolve this issue. I just haven't touched on some of the stuff that you guys are talking about that seem to work. Please pardon the ignorance on my part.

So now that we know for sure that cron is working and it's the script itself that has an issue because of the x server/display issue...what is the next step?

I'm looking into 'xauth' right now and will get back to you asap

THanks alot guys for all your efforts.
Soup

soupnsandwich · 07-29-2009, 09:54 PM

Ok I read some man pages on xauth. Although I'm not really sure how to use this as of right now I can see you guys think it's important to resolving this issue.

With that said I guess at this time I should mention that we have no way of knowing what any of the users login names will be. These systems, after install will prompt on the new root users password and username and the users password. So we will not have access to any usernames information because the OS gets installed by the dealer for the end user. We had plans on burning this script/cron job into the OS so it works from the get go. I guess I would have to find a way to set some type of variable for all users and root on the system. Or on first login of any new users it would as the end user to pick from a drop down menu his/her users name and then do some "sed" or "mv" and change the name of a preset cron job and display and change it to what the user set in a drop down box...ha ha...or something like that!

I don't know what I have to do until I get the end results of this testing and what we are left with.

THanks guys again.
SOup

micxz · 07-30-2009, 01:47 AM

Quote:

Originally Posted by soupnsandwich

Ok I read some man pages on xauth. Although I'm not really sure how to use this as of right now I can see you guys think it's important to resolving this issue.

Yes I think this is going to be the issue in allot of cases. Try starting another X session under a different user. And test as root trying to run apps in that users display.

Quote:

Originally Posted by soupnsandwich

With that said I guess at this time I should mention that we have no way of knowing what any of the users login names will be.

This does not matter as you will need use other means of finding out what users are logged in and using X. As in using commands like ps and others.

Quote:

Originally Posted by soupnsandwich

These systems, after install will prompt on the new root users password and username and the users password.

This does not make sense to me. You would never have to prompt for root pass when your talking about an already install system.

Quote:

OS gets installed by the dealer for the end user. We had plans on burning this script/cron job into the OS so it works from the get go.

Soup would you mind explaining the complete goal and function of you application? cron is one thing but we are now talking about many things.