LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Desktop
User Name
Password
Linux - Desktop This forum is for the discussion of all Linux Software used in a desktop context.

Notices


Reply
  Search this Thread
Old 07-29-2009, 01:15 AM   #46
micxz
Senior Member
 
Registered: Sep 2002
Location: CA
Distribution: openSuSE, Cent OS, Slackware
Posts: 1,131

Rep: Reputation: 75

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...
 
Old 07-29-2009, 12:21 PM   #47
soupnsandwich
Member
 
Registered: Jul 2009
Location: State of Rhode Island
Distribution: TBA
Posts: 34

Original Poster
Rep: Reputation: 15
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
 
Old 07-29-2009, 12:51 PM   #48
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian
Posts: 8,577
Blog Entries: 31

Rep: Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195
Hello Soup
Quote:
Originally Posted by soupnsandwich View Post
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
 
Old 07-29-2009, 01:00 PM   #49
soupnsandwich
Member
 
Registered: Jul 2009
Location: State of Rhode Island
Distribution: TBA
Posts: 34

Original Poster
Rep: Reputation: 15
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

Last edited by soupnsandwich; 07-29-2009 at 01:02 PM.
 
Old 07-29-2009, 01:40 PM   #50
soupnsandwich
Member
 
Registered: Jul 2009
Location: State of Rhode Island
Distribution: TBA
Posts: 34

Original Poster
Rep: Reputation: 15
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)
 
Old 07-29-2009, 01:40 PM   #51
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian
Posts: 8,577
Blog Entries: 31

Rep: Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195
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
 
Old 07-29-2009, 02:15 PM   #52
soupnsandwich
Member
 
Registered: Jul 2009
Location: State of Rhode Island
Distribution: TBA
Posts: 34

Original Poster
Rep: Reputation: 15
Interesting...ok something else to check out.

THanks
Soup
 
Old 07-29-2009, 07:13 PM   #53
jschiwal
LQ Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 677Reputation: 677Reputation: 677Reputation: 677Reputation: 677Reputation: 677
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!

Last edited by jschiwal; 07-29-2009 at 07:19 PM.
 
Old 07-29-2009, 07:57 PM   #54
micxz
Senior Member
 
Registered: Sep 2002
Location: CA
Distribution: openSuSE, Cent OS, Slackware
Posts: 1,131

Rep: Reputation: 75
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
 
Old 07-29-2009, 08:03 PM   #55
micxz
Senior Member
 
Registered: Sep 2002
Location: CA
Distribution: openSuSE, Cent OS, Slackware
Posts: 1,131

Rep: Reputation: 75
Quote:
Originally Posted by jschiwal View Post
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 View Post
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!
 
Old 07-29-2009, 08:11 PM   #56
jschiwal
LQ Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 677Reputation: 677Reputation: 677Reputation: 677Reputation: 677Reputation: 677
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
 
Old 07-29-2009, 08:22 PM   #57
micxz
Senior Member
 
Registered: Sep 2002
Location: CA
Distribution: openSuSE, Cent OS, Slackware
Posts: 1,131

Rep: Reputation: 75
Quote:
Originally Posted by jschiwal View Post
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!
 
Old 07-29-2009, 09:42 PM   #58
soupnsandwich
Member
 
Registered: Jul 2009
Location: State of Rhode Island
Distribution: TBA
Posts: 34

Original Poster
Rep: Reputation: 15
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

Last edited by soupnsandwich; 07-29-2009 at 09:47 PM.
 
Old 07-29-2009, 09:54 PM   #59
soupnsandwich
Member
 
Registered: Jul 2009
Location: State of Rhode Island
Distribution: TBA
Posts: 34

Original Poster
Rep: Reputation: 15
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

Last edited by soupnsandwich; 07-29-2009 at 09:57 PM.
 
Old 07-30-2009, 01:47 AM   #60
micxz
Senior Member
 
Registered: Sep 2002
Location: CA
Distribution: openSuSE, Cent OS, Slackware
Posts: 1,131

Rep: Reputation: 75
Quote:
Originally Posted by soupnsandwich View Post
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 View Post
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 View Post
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.

Last edited by micxz; 07-30-2009 at 01:50 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
cron job doesnt work, it works manually scofiled83 Programming 8 05-30-2009 03:12 PM
Why my cron job doesn't work byng08 Linux - Newbie 7 11-26-2008 01:17 AM
adding a perl script to cron.daily / cron.d to setup a cron job CrontabNewBIE Linux - Software 6 01-14-2008 08:16 AM
How do I get a cron job to work? socceroos Linux - Software 2 03-23-2006 04:22 PM
Cron Job petenyce Linux - Newbie 5 10-11-2005 04:03 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Desktop

All times are GMT -5. The time now is 03:03 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration