2

I have installed Hue in CentOS 7 from Cloudera CDH5 repository.

Upon starting it reports an error:

# systemctl status hue
hue.service - SYSV: Hue web server
   Loaded: loaded (/etc/rc.d/init.d/hue)
   Active: failed (Result: resources) since sob 2016-11-26 20:25:31 UTC; 6min ago
  Process: 3448 ExecStart=/etc/rc.d/init.d/hue start (code=exited, status=0/SUCCESS)

lis 26 20:25:20 node0 systemd[1]: Starting SYSV: Hue web server...
lis 26 20:25:20 node0 su[3457]: (to hue) root on none
lis 26 20:25:31 node0 hue[3448]: Starting hue: [  OK  ]
lis 26 20:25:31 node0 systemd[1]: PID file /usr/lib/hue/pids/supervisor.pid not readable (yet?) after start.
lis 26 20:25:31 node0 systemd[1]: Failed to start SYSV: Hue web server.
lis 26 20:25:31 node0 systemd[1]: Unit hue.service entered failed state.

This is false error, Hue has actually correctly started and created pid file under different directory (/var/run/hue/supervisor.pid).

# ps -ef | grep hue
hue       3877     1  0 20:25 ?        00:00:00 python2.7 /usr/lib/hue/build/env/bin/supervisor -p /var/run/hue/supervisor.pid -l /var/log/hue -d
hue       3949  3877  0 20:25 ?        00:00:03 python2.7 /usr/lib/hue/build/env/bin/hue runcherrypyserver

In /etc/init.d/hue pid directory is correctly set via PIDFILE variable... although I noticed also directory reported by systemctl as a comment:

# pidfile: /usr/lib/hue/pids/supervisor.pid
[...]
PIDFILE=/var/run/hue/supervisor.pid

Now I looked through all of /etc, /usr and /var and cannot find any piece of configuration that told systemd to look for pidfile in that specific directory. Any hint?

3

I […] and cannot find any piece of configuration that told systemd to look for pidfile in that specific directory.

You both can and did. You even put it in your question:

I noticed also [the] directory reported by systemctl as a comment:

# pidfile: /usr/lib/hue/pids/supervisor.pid

There it is. There's the configuration information that told systemd-sysv-generator where the PID file is.

Out of the several major different styles of rc scripts (Mewburn rc, OpenBSD rc, LFS, Fedora/RHEL/CentOS, SUSE, Debian/Ubuntu, and OpenRC) this is one of the two that systemd tries to import. The giveaway is the "SYSV:" that it has prepended to the description. When it imports the other style, it prepends "LSB:".

pid directory is correctly set via PIDFILE variable

"correctly" is an overstatement. Your old rc script is self-contradictory. The configuration information in its header contradicts what the script actually does.

One approach is to fix your self-contradictory rc script. A better one is to write a service unit instead. Using your incorrect rc script is resulting in the dæmon being run under two nested service managers, supervisor under systemd. Ironically, none of that PID file rubbish is even necessary in the first place.

It would look something like:

[Unit]
Description=Hue web server
Documentation=https://unix.stackexchange.com/a/326354/5132

[Service]
Type=simple
User=hue
WorkingDirectory=/usr/lib/hue/
Environment=PYTHON_EGG_CACHE=/tmp/.hue-python-eggs
ExecStart=/usr/bin/env build/env/bin/hue runcherrypyserver
SyslogIdentifier=hue

[Install]
WantedBy=multi-user.target

Further reading

  • Thank you! I wouldn't guess that this commented pidfile path actually means something. I tried both approaches (fixing rc script and providing unit file) and both work fine. Just for the unit file I needed to change WorkingDirectory=/var/lib/hue/, otherwise it complained about permissions. – Kombajn zbożowy Nov 27 '16 at 13:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.