Kjetil Svalastog Matheussen writes:

> Hi,
>
> I'm the author of a daemon called das_watchdog.[1] Das_watchdog uses
> xmessage [2] to let the user now when one or more run-away realtime
> processes have halted the system. This program has saved me and many
> others using realtime software from pressing the reset button numerous
> times.
>
> The trickiest thing this program does is to set the XAUTHORITY environment
> variable before calling system("xmessage ..."). Currently, the program
> searches through all running processes, checks the owner, and reads that
> owners .xauthority file [3]
>
> This approach usually works, but sometimes it doesn't because .xauthority
> is not used. The approach can also lead to more than one xmessage being
> displayed.
>
> So I wonder if anyone else has experience about doing this? Searching
> through deja, I found some others asking the same question:
> http://groups.google.com/group/comp....6b38fdb458614b
> but I could not find any (good) answers.
>
> My current plan is to search through all running processes, extract
> the XAUTHORITY value from their /tmp//environment file, and use
> those filenames in libXau to check the cookie-values to avoid duplicates.
> Is this a good idea, or are there better ways?

I'd say email is a whole lot better than xmessage.
Are your users always at :0?

I know I use my work system remotely quite frequently.
Coming into work and seeing an xmessage window notifying
me of a critical problem would be good for laughs.

On Wed, 3 Jan 2007, Dan Espen wrote:

> Kjetil Svalastog Matheussen writes:
>
> > Hi,
> >
> > I'm the author of a daemon called das_watchdog.[1] Das_watchdog uses
> > xmessage [2] to let the user now when one or more run-away realtime
> > processes have halted the system. This program has saved me and many
> > others using realtime software from pressing the reset button numerous
> > times.
> >
> > The trickiest thing this program does is to set the XAUTHORITY environment
> > variable before calling system("xmessage ..."). Currently, the program
> > searches through all running processes, checks the owner, and reads that
> > owners .xauthority file [3]
> >
> > This approach usually works, but sometimes it doesn't because .xauthority
> > is not used. The approach can also lead to more than one xmessage being
> > displayed.
> >
> > So I wonder if anyone else has experience about doing this? Searching
> > through deja, I found some others asking the same question:
> > http://groups.google.com/group/comp....6b38fdb458614b
> > but I could not find any (good) answers.
> >
> > My current plan is to search through all running processes, extract
> > the XAUTHORITY value from their /tmp//environment file, and use
> > those filenames in libXau to check the cookie-values to avoid duplicates.
> > Is this a good idea, or are there better ways?
>
> I'd say email is a whole lot better than xmessage.

As I wrote note in my previous posting:

"
[2] Sending mails or call syslog() are bad solution for this type of
daemon, because the user need to manually kill the offending processes
within a certain time frame.
"

The reason is that the watchdog should not destroy anything, and therefore
it just _temporary_ sets all realtime processes to non-realtime for a
certain amount of time. Default time is 8 seconds, and its very
unlikely that the user will read mail during these 8 seconds. (Well, some
people check mail more frequently than others, but still... :-) )



> Are your users always at :0?
>

Yeah, I would think so. But the /tmp//environment:XAUTHORITY approach
should anyhow solve that problem, I think...


> I know I use my work system remotely quite frequently.
> Coming into work and seeing an xmessage window notifying
> me of a critical problem would be good for laughs.
>

So far, this deamon is only used by audio people, as far as I know, and
there are very few who work with distributed audio processing over large
distances. I would be very surprised if anyone did that right now, as the
network latency probably is _way_ too high to defend running
remote programs with realtime priority.