2

I'm trying to run jenkins, via systemctl, and it keeps dying immediately after being started. There is nothing in the "systemctl status" nor in "journalctl". Jenkins logs also show nothing.

I've narrowed down the segment of code that starts the daemon. Inside the "daemon()" function in /etc/init.d/functions:

 $cgroup $nice runuser -s /bin/bash $user -c "$corelimit 2>&1 ; $*"

When I print this out, it shows:

runuser -s /bin/bash jenkins -c ulimit -S -c 0 >/dev/null 2>&1 ;  \
/etc/alternatives/java -Djava.awt.headless=true \
-Djenkins.install.runSetupWizard=false -DJENKINS_HOME=/var/lib/jenkins \
-jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log \
-webroot=/var/cache/jenkins/war --daemon --httpPort=8080 --debug=5 \
--handlerCountMax=100 --handlerCountMaxIdle=2

This runs fine when I manually run it from the CLI. It dies in less than a second when run through "daemon()" though.

This is running on Oracle Linux 7 UEK4 if that matters.

UPDATE: I tried the following scenarios:

1) systemctl start jenkins # FAILS
2) /etc/rc.d/init.d/jenkins start # FAILS
3) cp /etc/rc.d/init.d/jenkins /var/tmp; /var/tmp/jenkins start # SUCCESS

This is very strange...

MadHatter
  • 79,770
  • 20
  • 184
  • 232
wsaxton
  • 195
  • 11
  • Not sure what you mean. As I mentioned above, I ran the "runuser..." command in an interactive shell and it spawned the daemon just fine. – wsaxton May 25 '17 at 19:10
  • Ah, I think I failed at reading. Sorry about that. – Zoredache May 25 '17 at 19:36
  • `$cgroup` and `$nice` most likely have been set to something by systemd prior to executing the command you found, try logging your environment before the command is actually executed in the init script. – Ginnungagap May 26 '17 at 06:33
  • I don't have cgroups installed, so they are both empty. Using cgroups is optional. – wsaxton May 26 '17 at 20:07
  • If you can get rid of the >/dev/null bit, I'd go with that for debugging. Failing that, can you get an strace in there and dig from there? – Tollef Fog Heen May 27 '17 at 19:44
  • Yeah, I ended up getting rid of all >/dev/null's and printing out all environment variables and running commands manually. I found out that the issue was certain directories having the wrong permissions. Still, seemed like a real pain to jump through all these hoops when it seems like these errors should have been logged somewhere. – wsaxton May 29 '17 at 00:59
  • The errors *would* have been logged, had you not deliberately sent the logs to /dev/null instead. – Jenny D May 30 '17 at 07:36
  • I think you mean "the errors would have been logged had systemctl not been designed to squelch the logging of these commands". It's not like I wrote "/etc/init.d/functions" myself... – wsaxton May 31 '17 at 12:17

0 Answers0