Mailing List Archives

Public Access

 		[Computer Systems Lab]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 8/24/2015 11:03 AM, Antonio Dorta wrote:

Hi Michael and Greg!

We've been doing some tests with Michael's solution. I think it should
work, but it seems that current condor_kbdd has some problems when also
using condor_shared_port... I've also found some people asking the same,
but no replies so far
(https://www-auth.cs.wisc.edu/lists/htcondor-users/2015-April/msg00140.shtml)...
This incompatibility between condor_kbdd and the condor_shared_port has been fixed in the v8.3 series, specifically as of v8.3.7. See 
  https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=5058

regards,
Todd




This is what I get in kbdd.log:

...
Daemon Log is logging: D_ALWAYS D_ERROR
DaemonCore: command socket at <161.72.203.8:59273>
DaemonCore: private command socket at <161.72.203.8:59273>
Connected to X server: :0.0
WARNING: UDP does not support connecting to a shared port! (requested
address is <161.72.203.8:9618> with SharedPortID=20022_83d5_3
...
Stack dump for process 29848 at timestamp 1440430471 (15 frames)
/usr/pkg/condor/condor-8.2.9-x86_64_RedHat7-stripped/sbin/../lib/libcondor_utils_8_2_9.so(dprintf_dump_stack+0x72)[0x7eff35cf1812]

/usr/pkg/condor/condor-8.2.9-x86_64_RedHat7-stripped/sbin/../lib/libcondor_utils_8_2_9.so(+0x1becb7
[0x7eff35d73cb7]
/lib64/libpthread.so.0(+0x100d0)[0x7eff315b00d0]
/usr/pkg/condor/condor/sbin/condor_kbdd[0x40251d]
/lib64/libX11.so.6(_XIOError+0x4e)[0x7eff3320157e]
/lib64/libX11.so.6(_XEventsQueued+0x7d)[0x7eff331feebd]
/lib64/libX11.so.6(XPending+0x57)[0x7eff331f07d7]
/usr/pkg/condor/condor/sbin/condor_kbdd(_ZN10XInterface13ProcessEventsEv+0x28)[0x402b78]

/usr/pkg/condor/condor/sbin/condor_kbdd(_ZN10XInterface13CheckActivityEv+0x34)[0x4035c4]

/usr/pkg/condor/condor/sbin/condor_kbdd(_Z12PollActivityv+0x15)[0x403875]
/usr/pkg/condor/condor-8.2.9-x86_64_RedHat7-stripped/sbin/../lib/libcondor_utils_8_2_9.so(_ZN12TimerManager7TimeoutEPiPd+0x3e3)[0x7eff35e266f3]

/usr/pkg/condor/condor-8.2.9-x86_64_RedHat7-stripped/sbin/../lib/libcondor_utils_8_2_9.so(_ZN10DaemonCore6DriverEv+0x9be)[0x7eff35e0cc0e]

/usr/pkg/condor/condor-8.2.9-x86_64_RedHat7-stripped/sbin/../lib/libcondor_utils_8_2_9.so(_Z7dc_mainiPPc+0x13a4)[0x7eff35e2a734]

/lib64/libc.so.6(__libc_start_main+0xf0)[0x7eff31202fe0]
/usr/pkg/condor/condor/sbin/condor_kbdd[0x4023e1]


and then a core is created and daemon exits...

Any ideas?
Thanks!






Quoting Michael V Pelletier <Michael.V.Pelletier@xxxxxxxxxxxx>:


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.






--
Todd Tannenbaum <tannenba@xxxxxxxxxxx> University of Wisconsin-Madison
Center for High Throughput Computing   Department of Computer Sciences
HTCondor Technical Lead                1210 W. Dayton St. Rm #4257
Phone: (608) 263-7132                  Madison, WI 53706-1685