Least worst way to let a system daemon connect to the X server. - Xwindows

This is a discussion on Least worst way to let a system daemon connect to the X server. - Xwindows ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Least worst way to let a system daemon connect to the X server.

  1. Least worst way to let a system daemon connect to the X server.


    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?

    Thanks for any help.




    [1] http://www.notam02.no/arkiv/src/das_...g-0.2.5.tar.gz


    [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.


    [3]
    for(lokke=0;lokke char xauthpath[5000];
    struct passwd *pass=getpwuid(uids[lokke]);
    sprintf(xauthpath,"%s/.Xauthority",pass->pw_dir);
    if(access(xauthpath,R_OK)==0){
    setenv("XAUTHORITY",xauthpath,1);
    if(verbose)
    printf("Trying xauth like -%s-\n",pass->pw_dir);
    system(temp);
    }



  2. Re: Least worst way to let a system daemon connect to the X server.

    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.

  3. Re: Least worst way to let a system daemon connect to the X server.

    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.


+ Reply to Thread