On 10/23/2013 08:25 AM, Simo Sorce wrote:
On Wed, 2013-10-23 at 09:09 -0500, Michael Cronenworth wrote:
Should "systemctl stop foo.service" stop all parent and child service processes?
Example: GlusterFS starts a service daemon (glusterd) and a brick daemon
(glusterfsd). When a user issues "systemctl stop glusterd" the service daemon is
stopped but the brick daemon is left running.
I have recently learned that it is expected behavior[1], but this seems to be a
defeat of the purpose of the stop command. What is @devel thoughts?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1022542#c1
The justification here sounds wrong, if every package decides to
re-interpret the meaning of 'stop' as they please we quickly end up with
inconsistent behavior all over and diminish the usefulness of the
command, as people will not be able to just trust it and will have to go
around and test if it did what they asked for.
If glusterfs feels people need to run the bricks and the main daemons
separately then they should probably split service files and have a
dependency to bring one up when the other comes up, yet still be allowed
to take the daemon down w/o taking down the bricks.
Separate service files will make it clear you can operate on them
separately.
We did something similar for 389-ds-base. There can be multiple
instances of the 389-ds-base service, each with a systemd name of
dirsrv@INSTNAME.service. These can be individually stopped/started. We
also have a dirsrv.target which controls all instances.
http://port389.org/wiki/Howto:systemd
[2] I did not contact JoeJulian as I feel this is a Fedora issue and not a
GlusterFS issue.
Fedora tries to push systemd service files upstream, I think you should
involve glusterfs people and explain what they are doing wrong.
Simo.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
