Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong "pidFilePath:" setting in /etc/mongodb.conf on Debian #647

Closed
dhs-rec opened this issue Jul 21, 2022 · 11 comments
Closed

Wrong "pidFilePath:" setting in /etc/mongodb.conf on Debian #647

dhs-rec opened this issue Jul 21, 2022 · 11 comments
Labels
bug Something isn't working

Comments

@dhs-rec
Copy link
Contributor

dhs-rec commented Jul 21, 2022

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet: 7.x
  • Ruby: as delivered with Puppet
  • Distribution: Debian Buster
  • Module version: 4.1.1

How to reproduce (e.g Puppet code you use)

  class { 'mongodb::globals':
    manage_package_repo   => true,
    mongod_service_manage => true,
    version               => $version,
  }

  class { 'mongodb::server':
    ...
    fork           => false,
    pidfilepath    => undef,
    manage_pidfile => false,
    ...
    require        => Class['mongodb::globals'],
  }

What are you seeing

There's a pidFilePath: setting in /etc/mongodb.conf that shouldn't be there:

#Process Management
processManagement:
  pidFilePath: /var/run/mongod.pid

which leads to a server start failure on reboots because the pidfile isn't there and the mongod process has no permission to create it.

What behaviour did you expect instead

There should be no pidFilePath: setting in the file at all. The (MongoDB) documentation says:

If the processManagement.pidFilePath option is not specified, the process does not create a PID file. This option is generally only useful in combination with the processManagement.fork setting.

and

On Linux, PID file management is generally the responsibility of your distro's init system: usually a service file in the /etc/init.d directory, or a systemd unit file registered with systemctl. Only use the processManagement.pidFilePath option if you are not using one of these init systems.

As you can see above, $fork is explicitly set to "false" (the default of "undef" didn't work either). I worked around this by modifying templates/mongodb.conf.2.6.erb like so:

# git diff mongodb/templates/mongodb.conf.2.6.erb
diff --git a/mongodb/templates/mongodb.conf.2.6.erb b/mongodb/templates/mongodb.conf.2.6.erb
index 32c38be3..dfa66aaa 100644
--- a/mongodb/templates/mongodb.conf.2.6.erb
+++ b/mongodb/templates/mongodb.conf.2.6.erb
@@ -32,7 +32,7 @@ systemLog.verbosity: 5
 <% end -%>
 
 #Process Management
-<% if @fork or @pidfilepath -%>
+<% if @fork -%>
 processManagement:
   <%- if @fork -%>
   fork: <%= @fork %>

but I guess this is really just this, a workaround...

@dhs-rec dhs-rec changed the title Wrong "pidfilepath" setting in /etc/mongodb.conf on Debian Wrong "pidFilePath:" setting in /etc/mongodb.conf on Debian Jul 21, 2022
@dhs-rec
Copy link
Contributor Author

dhs-rec commented Dec 13, 2022

An update to 4.2.0 has now overwritten my workaround and thus has put the processManagement.pidFilePath into the file again, leading to a non-starting mongod.service again.

This means that the handling of this setting is still broken in 4.2.0. Can this please be fixed?

@kenyon
Copy link
Member

kenyon commented Dec 14, 2022

Is there a pull request for this?

@dhs-rec
Copy link
Contributor Author

dhs-rec commented Dec 14, 2022

The diff is in the description above.

@kenyon
Copy link
Member

kenyon commented Dec 14, 2022

I think it would be better to fix this line:

$pidfilepath = pick($mongodb::globals::pidfilepath, '/var/run/mongod.pid')

Since we only support Debian versions that use systemd, $mongodb::params::pidfilepath should end up undef.

@kenyon kenyon added the bug Something isn't working label Dec 14, 2022
@kenyon kenyon changed the title Wrong "pidFilePath:" setting in /etc/mongodb.conf on Debian Wrong "pidFilePath:" setting in /etc/mongodb.conf on Debian Dec 14, 2022
@dhs-rec
Copy link
Contributor Author

dhs-rec commented Dec 14, 2022

Yeah, as I wrote: My change was only a workaround.

@bastelfreak
Copy link
Member

Hi @dhs-rec, thanks for raising the issue. We're a small collective of module authors and maintain > 150 modules. It's not possible to provide fixes for all the issues that people raise. If you like, please provide a PR with the proposed change. We're also happy to guide you through our CI system or how to write tests. Feel free to hop into our IRC channel #voxpupuli on libera.chat or #voxpupuli on https://slack.puppet.com/.

@dhs-rec
Copy link
Contributor Author

dhs-rec commented Dec 15, 2022

@bastelfreak, I don't get this. Obviously, @kenyon already found the right place and what's needed to do the fix. He could as well have just committed it...

@kenyon
Copy link
Member

kenyon commented Dec 16, 2022

@dhs-rec Good luck, I certainly won't be helping you get anything fixed thanks to your ungrateful attitude.

@h-haaks
Copy link
Contributor

h-haaks commented Apr 29, 2024

@dhs-rec release 6.0.0 should solve this. Could you please verify?

@dhs-rec
Copy link
Contributor Author

dhs-rec commented Apr 30, 2024

Sure, I'll take a look as soon as possible. Thanks a lot for the hint.

@dhs-rec
Copy link
Contributor Author

dhs-rec commented Apr 30, 2024

Yes, looks good. Thanks for fixing this.

@dhs-rec dhs-rec closed this as completed Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants