Yes John, that's what appears to be happening
(or is not happening :) )
KBDD is in the daemon list and is starting under the
SYSTEM account.
But it does not seem to be adding a registry key so
that another KBDD
will start at logon time as the logged on
user.
Cheers
Greg
P.S. Interestingly enough, going through the MSI
install into c:\condor
doesn't seem to reproduce the other problem we came
across of the user
not having sufficient permissions to write to the
KBDD log file. The user
still doesn't have write permissions but the KBDD
running under the
user name does not fail with the MSI
install.
This problem is reproducible with our 2 methods of
install (kix script
and DOS batch script) which copy folders across. The user
does
not have write permissions on log so KBDD running as
user fails.
Below is the error message if starting manually from a
command prompt
on Win7 (it work OK if cmd prompt is runas
administrator).
>c:\progra~1\condor\bin\condor_kbdd.exe
-f
07/19/11 10:23:03 Can't open
"C:\PROGRA~1\condor/log/KbdLog.txt"
dprintf() had a fatal error in pid
976
Can't open "C:\PROGRA~1\condor/log/KbdLog.txt"
errno: 13 (Permission
denied)
From: condor-users-bounces@xxxxxxxxxxx
[mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of John (TJ)
Knoeller
Sent: Monday, 18 July 2011 10:16 PM
To:
condor-users@xxxxxxxxxxx
Subject: Re: [Condor-users] Win7 and kbdd
daemon
So, to be clear. When you start Condor, and KBDD is in
DAEMON_LIST.
KBDD does start under the SYSTEM account?
But
that instance of KBDD does NOT add a registry key so that another KBDD will
start as the logged on user?
or is it that the KBDD never starts as
SYSTEM?
-tj
On 7/14/2011 11:26 PM, Greg.Hitchen@xxxxxxxx wrote:
> 1. The condor_kbdd has to be listed under
DAEMON_LIST and be running under the system account in
> order to add itself to the registry. Also,
since it is a 32bit process, its registry edit may end up getting
redirected
> to the WOW64 registry. Are you sure that is
not what is happening?
I have rechecked
this a number of times. It is definitely in DAEMON_LIST and I can see it
running in taskmanager,
(along with
condor_master and condor_startd, all running as SYSTEM). I have checked both
the normal and WOW64
sections of the
registry and there is NO condor_kbdd entry.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
I have logged on/off and rebooted multiple
times but nothing changes.
> 2. The kbdd is the only daemon that should NOT
fail if it cannot write to the log. In fact, it specifically has
> code in place to not fail. What happens that
leads you to believe this is the cause?
If
I manually add condor_kbdd to the
registry to start at logon then I can very briefly see a cmd
prompt
flash up at logon
but I never see and extra condor_kbdd in the taskmanager.
If I then try to
manually start it from a normal command prompt I get the following
message.
c:\progra~1\condor\bin\condor_kbdd.exe
07/15/11 11:27:32 Can't
open "C:\PROGRA~1\condor/log/KbdLog.txt"
dprintf() had a fatal error in pid
4520
Can't open "C:\PROGRA~1\condor/log/KbdLog.txt"
errno: 13
(Permission denied)
If I open a
command prompt using runas administrator then condor_kbdd does run OK, I can
now
see it in
taskmanager (running under my username now) and it talks OK with the
startd.
So the only way I
can get it working (after adding it to the registry) is to change the
permissions
on the log
directory.
I have used
D_FULLDEBUG but nothing pertient seems to show up in the log
files.
The only other
difference I can think of is that we place the condor directory
in
Program Files.
Our kix
script refers to %ProgramFiles% so on 32 systems this is c:\program
files\
(or progra~1)
and on 64
bit systems this is c:\program files (x86)\ (or progra~2). On 64 bit
systems
we add a link so
that c:\program files\condor points to c:\program files
(x86)\condor
In all our config
files we refer to c:\progra~1\condor as in the past we have found that
the config
file cannot handle
folders with spaces in them. Maybe it's different for
7.6.1?
Please let us know
if we can supply any more info about this.
It's not a show
stopper for us as our install script adds workarounds to handle
it.
Thanks
Cheers
Greg
_______________________________________________
Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/condor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/condor-users/
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}