1

I've tried to set up a new server via our puppet-master. It was supposed to be a quick affair, everything in there has been running pretty reliably, and still is on the older servers.

Just that the new server is the first that is running Ubuntu 18, and puppet seems unable to start the services. Here's an example of an error I'm getting when trying to ensure a service is running:

Error: /Stage[main]/Influxdb/Service[influxdb]/ensure: change from stopped to running failed: Could not find init script for 'influxdb'

In the debug output I can see the following things:

Executing: '/usr/sbin/service influxdb status'
Service[influxdb](provider=debian): Could not find influxdb in /etc/init.d
Service[influxdb](provider=debian): Could not find influxdb.sh in /etc/init.d

There is in fact no file relating to the service in /etc/init.d, but that was never required before. If I run sudo /usr/sbin/service influxdb status from the console, the command works. So why is the puppet agent unable to manage the service exactly?

Note that I'm not 100% sure that the problem is with ubuntu 18. That's just the only significant thing I can think of that's changed, and apparently there were some changes with systemd in Ubuntu 18, though I'm not quite clear yet on what they are exactly. What I would like is a solution that does not require me to rewrite all my service files, and have a puppet setup that works on the servers still running the old OS as well as servers running the new one. Can anybody help me achieve this?

Improve this question
6
  • 2
    It looks like Puppet is trying to use the debian service provider rather than the systemd service provider. If you force provider => systemd in your Puppet service resource, does that help?
    – bodgit
    Feb 25, 2019 at 18:59
  • Yes! Yes it does! I didn't even see that option in the attributes... In any case, this helps a lot. It doesn't fix everything, since some of the calls are in 3rd party libraries where I can't do that. Is there a way to fix this in the OS? Since obviously there must be something that tells puppet what to use, otherwise it wouldn't work differently on two different distros...
    – UncleBob
    Feb 26, 2019 at 7:25
  • What version of Puppet are you using? It might be on older versions of Puppet that don't explicitly know about Ubuntu 18.x that the heuristics just default to the debian provider and this has been fixed in newer versions.
    – bodgit
    Feb 26, 2019 at 9:10
  • agent version is 4.10.12.
    – UncleBob
    Feb 26, 2019 at 10:20
  • 1
    Right, it's too old. It looks like Ubuntu 18.04 support was added in 5.3.6: github.com/puppetlabs/puppet/commit/…
    – bodgit
    Feb 26, 2019 at 10:25

2 Answers 2

Reset to default
2

So the cause of this is using too old a version of Puppet on too newer an OS. Puppet 4.10.12 (which the OP is using) doesn't know about Ubuntu 18.04 and the fact that it uses systemd as the chosen init system. The heuristics in that version of Puppet basically know that systemd is used on Ubuntu versions from 15.04 to 17.10 inclusive. In Puppet version 5.3.6 which officially adds support for Ubuntu 18.04, that version is added to the list of versions known to use systemd. In later versions of Puppet the logic is flipped to say systemd is used on every version of Ubuntu except versions 10.04 to 14.10 which should make things easier when the next Ubuntu release comes along.

Improve this answer
2

If I had encountered this issue, these are the steps I'd take:

  1. I'd take influxdb's init.sh script which by default can be found in your influxdb server, in path /usr/lib/influxdb/scripts/init.sh and copy it to /etc/init.d/influxdb.

  2. Make the script executable: chmod u+x /etc/init.d/influxdb

  3. Rerun Puppet again.

If you can't find that init script, then I've uploaded it to pastebin.com, here's the link (I took it from my server which runs version 1.6.4): https://pastebin.com/fkHRGfZH

If you want the service to start on boot time, run:

update-rc.d influxdb defaults

And it will copy the file you created in /etc/init.d/influxdb to each run levels you specified.

Improve this answer
5
  • Thank you, the suggested solution works... for influxdb. There are other services, though, some of them our own, so I can't fix the entire issue by just copying around a few files. I could fix it by writing init files for everything, of course, but I'd rather save myself the work and fix the underlying issue instead. After all, this behaviour doesn't seem normal, or is it? Puppet has been running for years now without a hitch using the unit files, I would consider regressing to inits a serious drawback...
    – UncleBob
    Feb 25, 2019 at 16:24
  • I agree with you. But which other services have this problem? it sounds to me like influxdb installation didn't finish properly because it's supposed as part of the installation to copy the init script to the /etc/init.d folder. Does it happen in other ubuntu 18 servers in your workplace?
    – Itai Ganot
    Feb 25, 2019 at 16:32
  • > But which other services have this problem? < All of them... the entire service resource is broken.
    – UncleBob
    Feb 25, 2019 at 22:45
  • Does it happen in all your Ubuntu 18 servers? Could it be a faulty installation? maybe re-installing the server or trying running Puppet on another server will yield some more information?
    – Itai Ganot
    Feb 26, 2019 at 9:54
  • There is currently only one with Ubuntu 18, so it's difficult to say. A complete server reinstall was among the first things I attempted, though. Puppet is still running reliably on all older servers, none have shown any problems.
    – UncleBob
    Feb 26, 2019 at 10:21

You must log in to answer this question.

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