I currently have an issue with starting lava-publisher. Whenever I run python manage.py lava-publisher I get output log: 2017-05-22 20:10:28,061 INFO publisher Dropping priviledges 2017-05-22 20:10:28,061 ERROR publisher Unable to lookup the user or the group 2017-05-22 20:10:28,062 ERROR publisher Unable to drop priviledges
I currently Have the same binaries in my own workstation and I am able to successfully connected to lava-publisher my output log gets: 2017-03-27 19:34:43,909 INFO publisher Dropping priviledges 2017-03-27 19:34:43,909 DEBUG publisher Switching to (lavaserver(126), lavaserver(133)) 2017-03-27 19:34:43,909 INFO publisher Creating the input socket at ipc:///tmp/lava.events 2017-03-27 19:34:43,910 INFO publisher Creating the publication socket at tcp://*:5500 2017-03-27 19:34:43,910 INFO publisher Creating the additional sockets: 2017-03-27 19:34:43,910 INFO publisher Starting the proxy
I followed same steps to install from same repository on both machines. I somehow think this has to do with user or group not stored in database but I am not sure. BTW: lava server/dispatcher both work well on both machines I just want to have an event notification client working on my second machine.
Thank you.
- Randy
On 22 May 2017 at 21:22, Duran, Randy G randy.g.duran@intel.com wrote:
I currently have an issue with starting lava-publisher. Whenever I run python manage.py lava-publisher I get output log:
That's the wrong command in the first place.
/etc/init.d/lava-publisher runs lava-server manage lava-publisher
so use: sudo service lava-publisher restart
That makes a massive difference. lava-publisher is not a trivial python script, it needs the django settings and the correct database.
Called locally with just manage.py, it will be using the development database which is empty (deliberately as that is how the unit tests run).
Only when testing the jinja2 templates are any calls made without using lava-server manage (or ./lava_server/manage.py for local unit tests using the empty development database).
If started with python, it has no access to the production database.
Thanks Neil, I was able to run command " sudo service lava-publisher restart " and o got in output log:
lockfile.LockFailed: failed to create /var/run/lava-publisher.pid 2017-05-22 14:16:04,990 Running LAVA Daemon Traceback (most recent call last): File "./lava-publisher", line 4, in <module> __import__('pkg_resources').run_script('lava-server===2350f8e1', u'lava-publisher') File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 738, in run_script self.require(requires)[0].run_script(script_name, ns) File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1499, in run_script exec(code, namespace, namespace) File "/usr/local/lib/python2.7/dist-packages/lava_server-2350f8e1-py2.7.egg/EGG-INFO/scripts/lava-publisher", line 40, in <module> main() File "/usr/local/lib/python2.7/dist-packages/lava_server-2350f8e1-py2.7.egg/EGG-INFO/scripts/lava-publisher", line 37, in main return daemonise(PIDFILE, LOGFILE) File "/usr/local/lib/python2.7/dist-packages/lava_server-2350f8e1-py2.7.egg/lava_server/daemonise.py", line 96, in daemonise child = Popen(args) File "/usr/lib/python2.7/subprocess.py", line 711, in __init__ errread, errwrite) File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory
Any ideas?
-Randy
-----Original Message----- From: Neil Williams [mailto:neil.williams@linaro.org] Sent: Monday, May 22, 2017 1:29 PM To: Duran, Randy G randy.g.duran@intel.com Cc: lava-users@lists.linaro.org Subject: Re: [Lava-users] lava-publisher Issue
On 22 May 2017 at 21:22, Duran, Randy G randy.g.duran@intel.com wrote:
I currently have an issue with starting lava-publisher. Whenever I run python manage.py lava-publisher I get output log:
That's the wrong command in the first place.
/etc/init.d/lava-publisher runs lava-server manage lava-publisher
so use: sudo service lava-publisher restart
That makes a massive difference. lava-publisher is not a trivial python script, it needs the django settings and the correct database.
Called locally with just manage.py, it will be using the development database which is empty (deliberately as that is how the unit tests run).
Only when testing the jinja2 templates are any calls made without using lava-server manage (or ./lava_server/manage.py for local unit tests using the empty development database).
If started with python, it has no access to the production database.
On 22 May 2017 at 22:18, Duran, Randy G randy.g.duran@intel.com wrote:
Completely trashed installation, sorry.
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 738, in run_script
Do *not* ever allow any part of LAVA or any dependency of any part of LAVA to use /usr/local/ for the python dependencies. It will always fail.
This is in the docs, please, never ever use pypi or virtualenv with LAVA. Only the Debian packages, nothing else.
Any ideas?
Yes. Install LAVA correctly - but first delete everything in /usr/loca/llib/python*/dist-packages/* and site-packages/*
Do not take shortcuts around LAVA. If your system isn't Debian, then get a virtual machine running Debian.
... and specifically, Ubuntu is not supported - only Debian.
Sorry, but it is very clear that you did not follow the documented steps for installation. No correct installation of LAVA ever has any python code in /usr/local/lib/python*/dist-packages/ or site-packages/
Local admin scripts, certainly. Dependencies of LAVA - never.
lava-users@lists.lavasoftware.org
-
Duran, Randy G -
Neil Williams