Addresses #74 by adding ability to assign names to services #77
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change allows user to provide a
-name <name>
argument that will be used instead of the PID in supervisors for services added from the command line by non-root users. For example:After this, the usual
immortalctl
commands of stop, start, and halt using the name work as usual. This makes non-root usage much more convenient, e.g.:This addresses #74 in that it makes running
immortalctl
commands easier for users, as they do not have to first determine the supervisor PID. This will make scripting easier, as well.As a design note, I first implemented this through the
-ctl
argument; however, it would have affected the behavior of the root use;immortal -ctl foo foocommand
would have tried to use~root/.immortal/
instead of/var/run/immortal
as was the behavior prior to my change. Since this was a breaking change (whether or not it was much used), I went with adding a new argument.-ctl
and-name
are not compatible;-ctl
always overrides-name
. One enhancement would be throwing an error if both are provided; that is not included in this patch.I do not know why github is listing both changes in the diff, since the other patch has been accepted and merged. I find github's behavior baffling sometimes.