Bug 737629

Michal, do you have any insight into the above?  Thanks.

(In reply to comment #0)
> Description of problem:
> On a systemd enabled system, "service mongod stop" successfully kills the
> mongod service.  However, the normal situation for mongod is to exit with a
> code of 12 when it receives a signal.

Is this documented somewhere? I found this description of the ways to stop mongod, but there's no mention of the exit code:
http://www.mongodb.org/display/DOCS/Starting+and+Stopping+Mongo#StartingandStoppingMongo-Stoppingmongod

> This confuses systemd, so that a further
> "system mongod status" reports the status as failed rather than dead.

Yes, systemd expects the usual UNIX behaviour where EXIT_SUCCESS is 0 and
a non-zero code means a failure/error.

> This is somewhat odd behavior on the part of mongod, but changing it would
> be an API break for mongod

With SysVinit the exit codes of daemons were always lost, because init simply threw them away.
Are there really any users depending on the fact that mongod's clean exit code
is 12?

> so I don't know how much support there would be in upstream mongodb
> to change this.

Please ask them to consider changing it.

> I'm hoping there is a way to get systemd to take exit
> code 12 as "normal", and report it dead.

I don't think there is. systemd can be convinced to ignore failures from the commands it executes, but this does not apply to the exit codes of the forked daemons.
If you believe it is necessary to have a way to specify in a unit file some exit codes as "normal", please file an RFE against systemd.

(In reply to comment #2)
> (In reply to comment #0)
> > Description of problem:
> > On a systemd enabled system, "service mongod stop" successfully kills the
> > mongod service.  However, the normal situation for mongod is to exit with a
> > code of 12 when it receives a signal.
> 
> Is this documented somewhere? I found this description of the ways to stop
> mongod, but there's no mention of the exit code:
> http://www.mongodb.org/display/DOCS/Starting+and+Stopping+Mongo#StartingandStoppingMongo-Stoppingmongod

I didn't find any documentation about it either.  I noticed it while starting and stopping mongod, and then I looked in the code at pch.h:

        EXIT_KILL = 12 ,

And indeed, the signal handler thread in mongod (db/db.cpp) uses EXIT_KILL when it receives SIGHUP, SIGINT, or SIGTERM.

> 
> > This confuses systemd, so that a further
> > "system mongod status" reports the status as failed rather than dead.
> 
> Yes, systemd expects the usual UNIX behaviour where EXIT_SUCCESS is 0 and
> a non-zero code means a failure/error.
> 
> > This is somewhat odd behavior on the part of mongod, but changing it would
> > be an API break for mongod
> 
> With SysVinit the exit codes of daemons were always lost, because init simply
> threw them away.
> Are there really any users depending on the fact that mongod's clean exit code
> is 12?
> 
> > so I don't know how much support there would be in upstream mongodb
> > to change this.
> 
> Please ask them to consider changing it.

I'll ask upstream and see if they will support this.

> 
> > I'm hoping there is a way to get systemd to take exit
> > code 12 as "normal", and report it dead.
> 
> I don't think there is. systemd can be convinced to ignore failures from the
> commands it executes, but this does not apply to the exit codes of the forked
> daemons.
> If you believe it is necessary to have a way to specify in a unit file some
> exit codes as "normal", please file an RFE against systemd.

OK, if I can't convince upstream to change the exit code, I'll open an RFE.

Thanks for the input.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Upstream bug: https://jira.mongodb.org/browse/SERVER-4872

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.