1

I am automating the startup of a Jenkins service on a Debian 9 machine.

My service works well. The service definition is :

[Unit]
SourcePath=/etc/init.d/jenkins
Description=LSB: Start Jenkins at boot time
Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target shutdown.target
After=remote-fs.target systemd-journald-dev-log.socket network-online.target
Wants=network-online.target
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutStartSec=5min
TimeoutStopSec=10s
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SysVStartPriority=2
ExecStart=/etc/init.d/jenkins start
ExecStop=/etc/init.d/jenkins stop

But the problem is when I reboot the node, the service does not come up automatically. I have to manually run systemctl start jenkins

Since Im deploying this VM automatically, doing a manual systemctl enable jenkins is not an option.

Once the new jenkins vm is created, it should already have the ability to start the service after a reboot.

Even if I do a manual systemctl enable jenkins, I get :

# systemctl enable jenkins
Synchronizing state of jenkins.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable jenkins
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.

Is there something Im missing here ?

Improve this question
1
  • 1
    "Since Im deploying this VM automatically, doing a manual systemctl enable jenkins is not an option." -> but it seems you're creating the jenkins.service file, so why is one (creating file) ok and the other one not? In any case, all systemctl enable does is create a symlink, so you can also do that (see answer below), it has exactly the same effect. Oh yeah do include an [Install] section in your unit file, that's pretty much required.
    – filbranden
    Feb 23, 2019 at 7:10

1 Answer 1

Reset to default
5

You do seem to be missing the [Install] section, just like it says. From the Jenkins website, Installing Jenkins as a Unix daemon, try adding this:

[Install]
WantedBy=multi-user.target

Note that their stock example calls java directly, versus forking off a shell script.

To enable the service to start at boot, run:

systemctl enable jenkins

Or manually create the symlink:

ln -s /etc/systemd/system/jenkins.service /etc/systemd/system/multi-user.target.wants/jenkins.service
Improve this answer
3
  • Yes I notice that this does solve the issue for running the systemctl enable jenkins. But is there a way to bootstrap this command so that I dont have to explicitly run it when I provision a new jenkins VM ?
    – Jason Stanley
    Feb 22, 2019 at 18:26
  • does your VM boot to multi-user?
    – Jeff Schaller ♦
    Feb 22, 2019 at 18:32
  • Yes it does boot to multi-user.
    – Jason Stanley
    Feb 22, 2019 at 18:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .