Re: [HTCondor-users] Problems detecting mouse/keyboard with Fedora

[Greg Thain <gthain@xxxxxxxxxxx>]

Michael:

Thanks for the comprehensive reply.  To sum up:  out of the box, the Linux HTCondor startd will try to detect keyboard usage on a machine by stat'ing various files in /dev, and looking at their most recent modification times.  For virtual terminals (pty's), this works well, but that assumes that users are typing in some kind of shell that runs in a pty.  It doesn't detect mouse movements, and it can't detect typing that doesn't happen inside of a pty (for example, in the email client I'm currently using). It does detect remotely ssh'd typing, though.

To detect the rest, condor needs to talk to the X windows server.  It uses a separate program to do this, the ill-named keyboard daemon (condor_kbdd).  Unfortunately, the kbdd needs permission to talk to the X server, which is why it usually runs as root, started by the master.  However, if your home directories are mounted from NFS, this may be a problem which Michael cleverly fixes below, otherwise, the keyboard daemon should work out of the box, and that's what we'd recommend.

This is all on Linux -- on Windows, the condor keyboard daemon alone detects keyboard activity.

Independently of the above, there is a configuration knob in condor, SLOTS_CONNECTED_TO_KEYBOARD, which can allow some number of condor slots to continue to be used by remote condor jobs, even when the local user is working at the machine.  The idea here is maybe you have an eight core desktop, and you are willing to let one or two cores be used by condor at all times.  The default for this knob should be all of the slots, so that when a local user is working at a machine, no condor jobs can run.  Unfortunately, there was a bug in condor 8.2.8 and earlier that set this default incorrectly, and would allow all but one slot to say running forever.  You can fix this by upgrading to 8.2.9, or by setting SLOTS_CONNECTED_TO_KEYBOARD to some large number.

I will leave as an exercise for the reader how to detect keyboard and mouse activity for any Linux systems which have completely switched from X to Wayland...

-greg

I'm running Red Hat Enteprise Linux 6 here, and had a similar issue with our workstations. I had tried running the kbdd as root, but since home directories are on a root-squashed NFS filesystem, it wasn't able to read the cookies for the users, and thus was unable to connect to the display to monitor activity. I'm not sure if it'll be exactly what you need, but hopefully it'll at least get you closer.

The trick in our case is that the condor_kbdd, in order to detect GNOME console activity, has to be attached with the user's session, and owned by the user. This is discussed in section 3.12.5 in the 8.2.9 manual, but it is a bit short of explicit guidance due to the variety of different platforms involved.

For the RHEL6 GNOME, you need to add an "htcondor-kbdd.sh" script to /etc/X11/xinit/xinitrc.d to start it up on login, and update /etc/gdm/PostSession/Default to shut it down on logout.

The gist of the htcondor-kbdd.sh file is:

if [ -x /usr/sbin/condor_kbdd ] ; then
        if [ -d $HOME/.kbdd.log ] ; then
                /bin/mv -f $HOME/.kbdd.log/KbdLog $HOME/.kbdd.log/KbdLog.old
        else
                if [ -e $HOME/.kbdd.log ] ; then
                        /bin/rm -f $HOME/.kbdd.log
                fi
        fi
        /usr/sbin/condor_kbdd -l $HOME/.kbdd.log -pidfile $HOME/.kbdd.pid
fi

This does some basic sanity checking as you can see, by rotating the log file from a previous session and removing any non-directory that might block the daemon's creation of the directory. The condor_kbdd drops into the background by itself, so doesn't need an &.

The PostSession/Default script runs as root, and for obvious security reasons condor_kbdd doesn't want to run as root, so you have to switch to the session owner to run condor_kbdd -k to kill the daemon. So we have:

if [ -f "$HOME/.kbdd.pid" ] ; then
        /bin/su $USER -c \
                "/usr/sbin/condor_kbdd -k $HOME/.kbdd.pid ; /bin/rm -f $HOME/.kbdd.pid"
fi

This approach is preferable to an OS kill because it allows the kbdd to take itself down 100% gracefully, doing whatever updates it needs to do before exiting.

After setting this up, the ConsoleIdle and KeyboardIdle attributes showed the expected responses to keyboard and mouse activity.

More information on these /etc/gdm scripts are here: https://help.gnome.org/admin/gdm/stable/configuration.html.en

It's probably possible to do everything under the /etc/gdm scripots, but the fact that they run as root led me to use the xinitrc.d options instead for startup, in alignment with the general recommendations in the manual. Feel free to share anything you discover that might simplify things.

        -Michael Pelletier.