Yes. You should run the debug script to prove cron is working as expected. Additionally you should add echo $DISPLAY to the debug code to check your values there.

Ok here is my new test script....it's having an issue with the 'DEBUG 20 (finished stuff) line. I'm a bit new at this stuff so please forgive my ignorance.
Just to make sure it still works for root only I did:

"crontab -e
i
* * * * * /root/Desktop/Notify > /dev/null
ESC
:wq"

I tested it. It works as long as 'DEABUG 20 (finished stuff) is commented out. I'm getting a syntax error in that line.

Once I get this debugging script working I'll move on to testing it again in the /etc/cron. folders for global cron jobs.

What do ya think?

"#!/bin/sh
export DISPLAY=:0.0
file="wget --spider http://www.websitehere.com/Notify/Notify.txt"
if $file; then
echo $DISPLAY
echo 'DEBUG 10 (just started)' 2>/tmp/DEBUG.$$ >&2

echo "file exists"
notify-send --urgency=normal -i /usr/share/icons/notify48.png -t 0 "Notification Alert" "Please click on the Notification Alert icon"



echo 'DEBUG 20 (finished stuff)' 2>/tmp/DEBUG.$$ >>&2




else
echo "file doesn't exist"
exit 0
fi"

Here is the syntax error I get when running that script in a terminal:

"Notify: line 25: syntax error near unexpected token `&'
Notify: line 25: `echo 'DEBUG 20 (finished stuff)' 2>/tmp/DEBUG.$$ >>&2'
"

Hey how do you do a "Code" section when I write code for you to see?

Launching a graphical program on a user's screen in a cron job, seems to me to be an odd choice for notification. Normally a log file is created, and the admin user or root is sent an email.

You need to test out your script as root from a virtual terminal, with the regular user logged into X. You may also need to use xauth to save root's cookie in the recipients home directory, and check that it is the expected user who owns the display before trying to send the notification.

Also use a logfile and email as backup notification.
Sometimes the same message is piped through "tee" for the log file and finally piped into nail or another program to send an email as well (all on the same line).

micxz:

Ok well even though the debugging script didn't work 100 percent at least it does something. So I took the crontab line out of the root and added it to the /etc/crontab file and commented out everything else and it doesn't run....after it just did run when it was in the root's contab (see below). So NOTHING is working out of the /etc/crontab it looks like.

I would listen to jschiwal he has a very good point these graphical notifications are not standard practice. And using a log and email should be incorporated.

post results:

ls -l /root/Desktop/Notify
cat /root/Desktop/Notify
whoami
crontab -l
cat /etc/crontab

Why root has a Desktop I don't understand as this is a risky running X as root! Again as jschiwal mentioned you need to be testing this logged in as a regular user and use sudo or su to edit for root.

I don't think that you understand what this is for.

These 3 different notifications isn't for the system itself. It's for my company to notify customers of possible patches, added features and/or critical service notifications.

The cron job doesn't control the notification at all...it runs the script and the script checks the notification page on our site. If a particular file exists it notifies the user. The cron job is there only for people that never shut their computer off. These scripts run globally at start up but if the person leaves the machine on the script never gets ran, and that's what the cron job is for.

Good idea on the virtual terminal. I'll have to try that one.

Thanks

But guys I'm just testing this stuff on the desktop of root. It's not staying there. It just to confirm it's actually running.

In this case you should only be using email and logging.

I'm starting to think I don't understand what this is for now.

You can't confirm it's actually running as expected if it's job is to notify regular users via X windows when your looking at the root desktop.To confirm it's running you need to reread this post and use the debugging methods described earlier.

make it simple in your script add after you do stuff:
echo DISPLAY=$DISPLAY >> /tmp/log.$$
do something
echo "do something is done" >> /tmp/log.$$
...

Thanks for the explaination. It explains what you are trying to do. I was thinking this was for notifying an admin user at a server, the results of a cron job.

The reason for logging as root in a VT, eg vt/2, is to test sending the graphical message to the logged in user, while having root not be in X. Except for more variables being set in the environment, the conditions are similar to the script running in cron.

Since this is for customers, you might need to check if the user's distro uses ConsoleKit and PolicyKit, and which Desktop environment is being used, and use a different script depending on the results.

A policy kit rule might say something like a regular authorized user may mount a DVD disc if logged in locally but not remotely. ( It would say that in xml'ese)
The ConsoleKit daemon is what determines if the user matches the criterium of the rule.

This is an area that is rapidly evolving. Just one minor revision earlier on my system, the udev rules were prominent. Now most of them are gone, and permissions to write to devices are done by adding a facl on the device node instead of creating a device node with the users group ownership, and modifying the permissions. Look at "ls -l /dev". The permissions that have a "+" at the end are examples.

I'm not sure whether this could effect root -> user popup notifications. Maybe the last two paragraphs are irrelevent.

Another evolving area is how notifications are handled in desktop environments. KDE 4 and Gnome now use the dbus daemon for communications between daemons and the desktop. hald/KDE and hald/Gnome communications are handled this way. Also a user may come to expect a non-modal notification popup when using KDE 4 or the latest Gnome desktop.

What you are doing sounds similar to a distro's update notification. On my system, SuSE, a bubble dialog fades in with a message that there are updates available. There is an applet that sits in the notification area of the task bar. Looking at how a multi-desktop* distro, such as SuSE or Fedora, do the same could be instructive. Trying to put my myself in the shoes of a customer, a kde or gnome applet which catches signals and displays text messages from a cron job may be less intrusive than an Xauth cookie in the home directory.

In any event, you should test whatever you come up with, on different distro's & versions. Sounds like a job for Virtual box!

Good Luck!
* By a multi-desktop distro, I mean one where you can install the desktop of your choice from the DVD or CD, and have the same menu and notifications work in all of them.

micxz,

I ran into this later:
http://crunchbanglinux.org/forums/to...ty-notifysend/

Here is the manpage for notify-send:
http://manpages.ubuntu.com/manpages/...fy-send.1.html

This post deals with notifications for Gnome & KDE. The same issues of the SCREEN variable, and xauth came up.
As well as not assuming that the logged in user was using screen :0.0.

http://forums.opensuse.org/programmi...-gui-wise.html


Hope these might help a little.

Good Luck!

Great links! I hope it clears things up for the OP as it did for me.

OK when I tested I can get a cron job to notify an x session only if the regular user allows it via:
Othe wise I got the error:
libnotify-Message: Unable to get session bus: dbus-launch failed to autolaunch D-Bus session: Invalid MIT-MAGIC-COOKIE-1 keyAutolaunch error: X11 initialization failed.

Here's what I have setup to test:

Micxz. Please reread some of the links. Don't use xhost to allow anyone to write to the screen. Use xauth and drop a cookie in the home directory instead. xhost can be a security hole.

I thought I was only allowing root to write to my screen from localhost with this command? I wasn't able to get the cookies to work correctly but I must have done it wrong. I will check again' Thanks for the heads up'