Some use cases start all services using the command:

immortal <command>

An example might be a user of herbstluftwm or bspwm, where it is canonical to put desktop initialization code in a single startup script. Since immortal does not provide a way of setting the service name via the command line, services started this way invariably get a numeric name. This makes it troublesome for users to start and stop services; the user must always check the output of immortalctl to find the PID of the immortal command managing the service, which cannot (without the PR to address #73) be easily scripted; or else write a non-trivial script to get such information from ps. The inconvenience is compounded by additional factors:

• commands are buried in the immortaldir, in subdirectories; crawling and parsing this information to find the command and then from that the PID of the parent immortal process is non-trival
• while structured data is provided (e.g. JSON), no facility is provided to extract top-level information. Structured data can only be retrieved for a single service, and only via the name of the service -- which in this case is the very PID being sought

Using PIDs for names is a logical decision and avoids conflicts (e.g., if immortal is managing multiple "polybar" instances), but the fact that no tools are provided to dereference these makes scripting immortalctl cumbersome.

Two improvements which could alleviate this are:

1. provide an argument (e.g. -name) for immortal that abstracts the -ctl argument without requiring hard-coded paths
2. fix -ctl so that it works for user immortal processes (it currently appears to be hard-coded to /var/run/immortal)
3. provide a mechanism for matching services by commands, rather than names

These solutions are complementary, and while both would be useful, having at least one would make working with and scripting immortalctl easier. The second item alone would alleviate the first, and make more sense, as the argument is otherwise useless to non-root users.