Hi Neil et al,
I'm trying to debug a simple qemu job that goes straight from running to
incomplete without log creation (used to working ok, but I reinstalled
everything on a different machine...)
Looking at /var/log/lava-server/lava-scheduler.log I see the following:
2015-12-09 15:22:27,838 [INFO] [lava_scheduler_daemon.job.JobRunner.14]
starting job {u'timeout': 18000, 'health_check': False, u'job_name':
u'qemu-arm-test', u'actions': [{u'command': u'deploy_linaro_kernel',
u'parameters': {u'login_prompt': u'login:', u'kernel': u'
http://images.validation.linaro.org/functional-test-images/qemu-arm/zImage-…',
u'username': u'root', u'rootfs': u'
http://images.validation.linaro.org/functional-test-images/qemu-arm/core-im…'}},
{u'command': u'boot_linaro_image', u'parameters': {u'test_image_prompt':
u'root@qemu-system-arm:~#'}}], u'target': u'qemu0'}
2015-12-09 15:22:27,838 [INFO] [lava_scheduler_daemon.job.MonitorJob]
monitoring "setsid lava-server manage schedulermonitor 14 lava-dispatch
qemu0 /tmp/tmpPd4nGs -l info -f /var/log/lava-server/lava-scheduler.log"
2015-12-09 15:22:29,171 [INFO] [lava_scheduler_daemon.job.Job.qemu0]
executing "lava-dispatch /tmp/tmpFltuQQ --output-dir
/var/lib/lava-server/default/media/job-output/job-14"
2015-12-09 15:22:30,388 [INFO]
[lava_scheduler_daemon.job.DispatcherProcessProtocol] childConnectionLost
for qemu0: 0
2015-12-09 15:22:30,389 [INFO]
[lava_scheduler_daemon.job.DispatcherProcessProtocol] childConnectionLost
for qemu0: 1
2015-12-09 15:22:30,389 [INFO]
[lava_scheduler_daemon.job.DispatcherProcessProtocol] childConnectionLost
for qemu0: 2
2015-12-09 15:22:30,389 [INFO]
[lava_scheduler_daemon.job.DispatcherProcessProtocol] processExited for
qemu0: A process has ended with a probable error condition: process ended
with exit code 1.
2015-12-09 15:22:30,389 [INFO]
[lava_scheduler_daemon.job.DispatcherProcessProtocol] processEnded for
qemu0: A process has ended with a probable error condition: process ended
with exit code 1.
2015-12-09 15:22:30,389 [INFO] [lava_scheduler_daemon.job.Job.qemu0] job
finished on qemu0
2015-12-09 15:22:30,389 [INFO] [lava_scheduler_daemon.job.Job.qemu0] job
incomplete: reported 1 exit code
2015-12-09 15:22:30,422 [INFO]
[lava_scheduler_daemon.dbjobsource.DatabaseJobSource] job 14 completed on
qemu0
I tried to run manually:
setsid lava-server manage schedulermonitor 14 lava-dispatch qemu0
qemu-arm.json
powerci@lab-baylibre:~/POWERCI/scripts/user$ 2015-12-09 15:23:23,285
[ERROR] [lava_scheduler_daemon.job.Job.qemu0] AttributeError: 'Job' object
has no attribute '_protocol'
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line
1203, in mainLoop
self.runUntilCurrent()
File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line
798, in runUntilCurrent
f(*a, **kw)
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line
393, in callback
self._startRunCallbacks(result)
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line
501, in _startRunCallbacks
self._runCallbacks()
--- <exception caught here> ---
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line
588, in _runCallbacks
current.result = callback(current.result, *args, **kw)
File "/usr/lib/python2.7/dist-packages/lava_scheduler_daemon/job.py",
line 226, in _run
self.cancel(exc)
File "/usr/lib/python2.7/dist-packages/lava_scheduler_daemon/job.py",
line 157, in cancel
self._protocol.transport.signalProcess(getattr(signal, signame))
exceptions.AttributeError: 'Job' object has no attribute '_protocol'
Note that I get the same issue with other jobs (boards, kvm): submission is
OK, but incomplete, and no log.
Any help would be much appreciated!
Many thanks,
Marc.
Hi,
is it possible to interact with a host tool (running on the dispatcher
host) to gather arbitrary key values and post them into the test result
stream. IOW, How do I add a MEASUREMENT/UNITS values using the output of
a host tool (no target shell interaction) ?
Thanks,
Marc.
Hi Neil et al.
I'm working at add my switching device to lavapdu deamon, so I pull Matt's
github etc...but when trying to restart the daemon I get the following
error:
déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: Reading
settings from /etc/lavapdu/lavapdu.conf
déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: Traceback
(most recent call last):
déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: File
"/usr/sbin/lavapdu-runner", line 103, in <module>
déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: context =
daemon.DaemonContext(
déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]:
AttributeError: 'module' object has no attribute 'DaemonContext'
déc. 04 15:56:49 powerci-lava-disp lavapdu-runner[3081]: ...fail!
déc. 04 15:56:49 powerci-lava-disp systemd[1]: lavapdu-runner.service:
Control process exited, code=exited status=1
déc. 04 15:56:49 powerci-lava-disp systemd[1]: Failed to start LSB:
LAVA PDU Runner.
déc. 04 15:56:49 powerci-lava-disp systemd[1]: lavapdu-runner.service:
Unit entered failed state.
déc. 04 15:56:49 powerci-lava-disp systemd[1]: lavapdu-runner.service:
Failed with result 'exit-code'.
I tried to revert to the master branch, re-installed with setup.py
with no success. The json config file seems ok.
Any clue?
Many Thanks,
Marc.
Hi All,
I'm setting up a local LAVA scheduler+dispatcher (standalone).
I'm able to posts jobs, but I think I'm missing an initial configuration
for some actions to complete, namely
action deploy_linaro_image
the eMMC flash content of my BBB-RevB6 is pretty standard (debian-7.9 of
2015-11-03, 2gb image).
Based on the log, the dispatcher expects the default "testboot" and
"testrootfs" partitions with offset 2, I assuime this means that those
partitions must be manually created the first time with index 3 and 4 in
order for this to work.
I would appreciate some hints, to avoid unnecessary test-and-try, what
would be the expected partitionning for BBB with LAVA ?
Thanks in advance,
best regards,
Marc.
Please let us know if you are using OpenID authentication with LAVA.
Newer versions of django will make it impossible to support
django-openid-auth in Debian unstable and testing. The version of
django-openid-auth in Jessie can continue to be used, so we would like
to know how many users want to continue with this support.
OpenID as a protocol has been dying for some time and Linaro has moved
over to LDAP, which is fine if LDAP is already available.
The time pressure for this change is coming from the schedule to get
the latest django and the latest lava packages into Ubuntu Xenial
16.04LTS which means that support needs to be implemented in the
2015.12 or 2016.1 LAVA releases. This is why this is quickly following
the trusty change. We have been aware of the issues with
django-openid-auth for some time, it was only when we had completed
the move of the Cambridge lab to LDAP that changes involving
django-openid-auth could be considered.
If you are using OpenID authentication (e.g. using Launchpad or Google
OpenID), please let us know.
If you would like to see some other forms of authentication supported,
also let us know. We can investigate Python Social Auth
(http://psa.matiasaguirre.net/), if there is interest.
If we don't hear from users who want django-openid-auth support for
use on Debian Jessie, we will drop django-openid-auth support from all
lava builds. This will leave LDAP and local Django accounts in
2015.12.
If anyone has experience of other django authentication modules, also
let us know.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
