Hudson Slave environment

[David Antliff]

Hi,

I look after a couple of independent Hudson servers that just happen
to be almost identical (both run Windows XP, both run Hudson 1.385,
both have the same software installed). We use these servers to build
FPGA images, which is a bit like C compilation, only different.

I want to set up the second server as a Hudson Slave, so that the
Master sends an FPGA build job over to the second machine. It has all
the FPGA software installed there so it should "just work".

I'm using Cygwin's ssh to start the slave application, and I have the
same user on both machines. I'm using Cygwin & git to check out the
source code and run the Makefiles that invoke the FPGA tools.

I've got the slave working fine, and non-FPGA build jobs seem to work
fine, but our FPGA jobs fail. They use software called "Lattice
ispTOOLS", version 8.1, that is installed on both the master and
slave. If I run a build manually (git clone, make, etc) on the second
server, it builds without error, but if I try and run the job via
Hudson on the second server (i.e. the slave), then I get an unusual
error message:

"Copyright (c) 1991-2010 Lattice Semiconductor Corporation, All
rights reserved.
Failed to get 'Config' context string of ispLever System
Failed to get 'Root' context string of ispLever System
"

I thought it might be due to a missing environment variable, however
I've checked through on both machines and I haven't been able to
locate anything missing that seems relevant.

Google Search doesn't bring up much for these error messages. I'm
wondering if there's some sort of Registry access problem when running
the job via SSH?

Can anyone give me some tips on how to diagnose this problem please?
What sorts of things could I try to debug this? What things might
differ between the ssh environment that slave.jar runs within, and the
environment I get when I simply run Cygwin directly?

Thank you.

[David Antliff]

On Jan 17, 4:52 pm, David Antliff <david.antl...@gmail.com> wrote:
> I thought it might be due to a missing environment variable, however
> I've checked through on both machines and I haven't been able to
> locate anything missing that seems relevant.

It has occurred to me that this may be caused by the program being
invoked (Synplify Pro) not being a true command-line program. Perhaps
instead it is trying to perform some GUI operations, and I'm not sure
how this would work when invoked via SSH. When I tried to run the tool
directly (which would normally bring up a project GUI), it gives me
the same error message.

Perhaps then this is a Cygwin issue rather than a Hudson issue? Any
comments please?

[riccardo]

I noticed a similar problem when running a Hudson job on a Windows-Slave.
Instead of SSH Hudson's Windows service was used to execute the build on the
slave.
The build failed because target "end" in ant.bat wasn't found.
If I called ant.bat manually on the slave this error didn't occur.

I fixed the problem by running the Windows service for Hudson on the slave
with a local
account instead of "local service".

So, perhaps you should check if some Windows service is involved in your
situation and
if it runs as local service and change it (e.g. using the account the manual
build works for).
--
View this message in context: http://hudson.361315.n4.nabble.com/Hudson-Slave-environment-tp3220662p3223609.html
Sent from the Hudson users mailing list archive at Nabble.com.

[David Antliff]

On Jan 19, 6:50 am, riccardo wrote:
> David Antliff wrote:

> > On Jan 17, 4:52 pm, David Antliff wrote:
> >> I thought it might be due to a missing environment variable, however
> >> I've checked through on both machines and I haven't been able to
> >> locate anything missing that seems relevant.
>
> > It has occurred to me that this may be caused by the program being
> > invoked (Synplify Pro) not being a true command-line program. Perhaps
> > instead it is trying to perform some GUI operations, and I'm not sure
> > how this would work when invoked via SSH. When I tried to run the tool
> > directly (which would normally bring up a project GUI), it gives me
> > the same error message.
>
> > Perhaps then this is a Cygwin issue rather than a Hudson issue? Any
> > comments please?
>
> I noticed a similar problem when running a Hudson job on a Windows-Slave.
> Instead of SSH Hudson's Windows service was used to execute the build on the
> slave.
> The build failed because target "end" in ant.bat wasn't found.
> If I called ant.bat manually on the slave this error didn't occur.
>
> I fixed the problem by running the Windows service for Hudson on the slave
> with a local
> account instead of "local service".
>
> So, perhaps you should check if some Windows service is involved in your
> situation and
> if it runs as local service and change it (e.g. using the account the manual
> build works for).

Hi riccardo, thank you for your reply.

I'm currently investigating this, and I've tried running under local
account as well as "local system" (or service). I haven't had much
luck but I've been using ProcessMonitor to work out where the
'working' and 'non-working' cases diverge. I haven't found a solution
yet but it looks like it's probably a permissions problem.

-- David.

[David Antliff]

On Jan 20, 1:13 pm, David Antliff wrote:
> I'm currently investigating this, and I've tried running under local
> account as well as "local system" (or service). I haven't had much
> luck but I've been using ProcessMonitor to work out where the
> 'working' and 'non-working' cases diverge. I haven't found a solution
> yet but it looks like it's probably a permissions problem.

I have found a solution - a missing and somewhat obscure environment
variable was not being set via SSH login.

-- David.