Core Server
  1. Core Server
  2. SERVER-7285

Cannot start mongodb with init scripts with Fedora 15 or above (support systemd)

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major - P3 Major - P3
    • Resolution: Unresolved
    • Affects Version/s: 2.2.0
    • Fix Version/s: Planning Bucket A
    • Component/s: Packaging, Usability
    • Labels:
      None
    • Environment:
      Fedora >= 15, RHEL7
    • Backport:
      No
    • Operating System:
      ALL
    • Bug Type:
      Unknown
    • # Replies:
      13
    • Last comment by Customer:
      true

      Description

      Hello,
      I cannot start mongodb 2.2.0 on Fedora 17
      got the error
      Oct 05 12:59:50 Evkalipt runuser[1787]: pam_unix(runuser:session): session opened for user mongod by (uid=0)
      Oct 05 12:59:50 Evkalipt mongod[1783]: Starting mongod: can't open [/var/log/mongo/mongod.log] for log file: errno:13 Permission denied
      Oct 05 12:59:50 Evkalipt runuser[1787]: pam_unix(runuser:session): session closed for user mongod

      permissions are ok for mongod user

      drwxr-xr-x. 2 mongod mongod 4096 Oct 5 12:41 /var/log/mongo
      rw-r----. 1 mongod mongod 0 Aug 28 22:42 mongod.log

      Thanks,
      Edouard

        Issue Links

          Activity

          Hide
          Edouard Perov
          added a comment -

          Hi Mark,
          I installed 2.0.7 from EPEL.
          Actually, I do not need a fix for that because can start the MongoDB directly with the command.
          Thanks for your help.
          Edouard

          Show
          Edouard Perov
          added a comment - Hi Mark, I installed 2.0.7 from EPEL. Actually, I do not need a fix for that because can start the MongoDB directly with the command. Thanks for your help. Edouard
          Hide
          Mark Hillick (Inactive)
          added a comment -

          Hi Edouard,

          Thanks for your update and that's what I thought and explains why 2.0.7 works via "service".

          I will update this ticket with our progress.

          Thanks

          Mark

          Show
          Mark Hillick (Inactive)
          added a comment - Hi Edouard, Thanks for your update and that's what I thought and explains why 2.0.7 works via "service". I will update this ticket with our progress. Thanks Mark
          Hide
          Tim Hawkins
          added a comment -

          I'm not sure where this issue is coming from, but my experiences while not ideal are quite different on Fedora 17

          I have alsways installed all my copies of Mongo on F16 and F17 from the mongodb Repo using "yum install mongo-10gen mongo-10gen-server"

          There IS a failure mode, but for me its not related to permissions, systemd when presented with a new init.d script, reads the script and creates the systemd unit file automaticaly. The mongod init.d script has an incorrect pidfile path which points to a non-existant pidfile.

          changing this comment to (for the default install)

          1. pidfile: /var/lib/mongo/mongod.lock

          and rerunning

          sudo systemctl --system daemon-reload

          causes systemd to reimport the init.d script and rebuild the systemd unit file.

          So now systemd can find the mongod.lock file which contains the running server pid.

          Without this two things will happen.

          1. Starting mongod with
          service mongod start

          will stall, as its waiting for the pid file to be created, mongod actualy starts up, but the command never returns.

          2. If you have executed
          sudo chkconfig mongod on

          to get mongo to startup at boot, then your system will hard hang on restart, and you will have to use the emergency console to recover your system.

          Show
          Tim Hawkins
          added a comment - I'm not sure where this issue is coming from, but my experiences while not ideal are quite different on Fedora 17 I have alsways installed all my copies of Mongo on F16 and F17 from the mongodb Repo using "yum install mongo-10gen mongo-10gen-server" There IS a failure mode, but for me its not related to permissions, systemd when presented with a new init.d script, reads the script and creates the systemd unit file automaticaly. The mongod init.d script has an incorrect pidfile path which points to a non-existant pidfile. changing this comment to (for the default install) pidfile: /var/lib/mongo/mongod.lock and rerunning sudo systemctl --system daemon-reload causes systemd to reimport the init.d script and rebuild the systemd unit file. So now systemd can find the mongod.lock file which contains the running server pid. Without this two things will happen. 1. Starting mongod with service mongod start will stall, as its waiting for the pid file to be created, mongod actualy starts up, but the command never returns. 2. If you have executed sudo chkconfig mongod on to get mongo to startup at boot, then your system will hard hang on restart, and you will have to use the emergency console to recover your system.
          Hide
          Angel Rivera
          added a comment -

          Tim

          I can confirm your fix works. I just had this same issue with my new Fedora install. I changed the commented line to pidfile: /var/lib/mongo/mongod.lock and ran the sudo systemctl --system daemon-reload command and it fixed the issue.

          I downloaded the mongodb 2.2.2 from the 10gen repos using yum and the boot problem occurred immediately after I rebooted.

          Show
          Angel Rivera
          added a comment - Tim I can confirm your fix works. I just had this same issue with my new Fedora install. I changed the commented line to pidfile: /var/lib/mongo/mongod.lock and ran the sudo systemctl --system daemon-reload command and it fixed the issue. I downloaded the mongodb 2.2.2 from the 10gen repos using yum and the boot problem occurred immediately after I rebooted.
          Hide
          Tim Hawkins
          added a comment -

          The fix i have given only really works for a standard default install, if the user reconfigures the server to have its data-files in a different place, the problem will resurface.

          Im not sure how best to fix this, putting the pid file into a fixed place like /var/run/mongod.pid would cause problems with multiple instances, which are quite common on mongo installations.

          Perhaps having the init.d script set the pid path by the command-line setting, as /var/run/mongod.pid, is acceptable, so folks can set the datadir to whatever they like via the conf file, so long as documentation is made available for troubleshooting if it should stall.

          The problem is really in systemd, it should never stall, and should time out with a suitable error message. The fact that you can get you system into a non bootable state with this is not good.

          Show
          Tim Hawkins
          added a comment - The fix i have given only really works for a standard default install, if the user reconfigures the server to have its data-files in a different place, the problem will resurface. Im not sure how best to fix this, putting the pid file into a fixed place like /var/run/mongod.pid would cause problems with multiple instances, which are quite common on mongo installations. Perhaps having the init.d script set the pid path by the command-line setting, as /var/run/mongod.pid, is acceptable, so folks can set the datadir to whatever they like via the conf file, so long as documentation is made available for troubleshooting if it should stall. The problem is really in systemd, it should never stall, and should time out with a suitable error message. The fact that you can get you system into a non bootable state with this is not good.

            People

            • Votes:
              5 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since reply:
                1 year, 16 weeks, 5 days ago
                Date of 1st Reply: