Skip to content

Allows systemd to track libvirtd without forking.#64

Closed
nelsonjr wants to merge 1 commit into
thias:masterfrom
nelsonjr:master
Closed

Allows systemd to track libvirtd without forking.#64
nelsonjr wants to merge 1 commit into
thias:masterfrom
nelsonjr:master

Conversation

@nelsonjr
Copy link
Copy Markdown

@nelsonjr nelsonjr commented Aug 6, 2016

On systems with services managed by systemd, e.g. Ubuntu 16.04, forking libvirtd to the background confuses systemd, which loses track of the service. As the calling process terminates, systemd incorrectly believes the service is dead and flags it as error/inactive/dead.

This patch does not use the default "-d" flag on those systems.

@mmogylenko
Copy link
Copy Markdown

Can we merge that?

Comment thread manifests/params.pp
$sysconfig = false
$deb_default = {}
$deb_default = $::service_provider ? {
'systemd' => { 'libvirtd_opts' => '' }, # no '-d', it confuses systemd
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure that this is sufficient? on the 16.04 box I have here service_provider is 'debian' not 'systemd'. Could be a version thing, this is with Puppet 3.8.5, Facter 2.4.6, Stdlib 4.12, masterless.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure? Can you confirm that by running: facter --puppet service_provider

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I got the issue. I'll assume you are running Debian 7. Until Debian 8 it has a special service provider. On Debian 8 it uses systemd. I did not test on init-style systems but for those the -d seems to be the right way to go.

Are you experiencing the same issue I got with systemd?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nelsonjr I have multiple Ubuntu 16.04 boxes with the Puppet/Facter that ship with that version of the OS, they all report service provider as debian:

root@Ubuntu-1604-xenial-64-minimal /etc/puppet # facter -p service_provider debian
My puppet environment is Puppet 3.8.5, Facter 2.4.6, Stdlib 4.12, masterless. What's yours?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting this could change with the Puppet distribution. I'm running the latest puppet 4.6.0. I did not run with Puppet 3. Do you have this issue with Puppet 3? According to the debian provider it uses a init based system (which is super weird Puppet 3 report that on Ubuntu 16). I'll try to install a new machine with Ubuntu 16 + Puppet 3 and dig into it.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After applying this PR I get the following error:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Syntax error at '{'; expected '}' at /etc/puppet/environments/development/modules/libvirt/manifests/params.pp:26

Some info about my environment:

h1 ~ # uname -a
Linux h1 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

h1 ~ # lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

h1 ~ # puppet --version
3.8.5

h1 ~ # facter --version
2.4.6

h1 ~ # facter -p service_provider debian
debian => nil
service_provider => nil

petems added a commit to petems/puppet-libvirt that referenced this pull request Jul 10, 2017
Merging these PR's that fix issues for me:
* thias#64
* thias#52
* thias#63
* Moves tests/ to examples/
* Changes meta-data to my fork petems-libvirt
* Eventually use the Vox Pupuli fork:
  * thias#74
@nelsonjr nelsonjr closed this Jul 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants