serviceman icon indicating copy to clipboard operation
serviceman copied to clipboard

Feature request: command to remove or edit a service

Open lahwran opened this issue 4 years ago • 6 comments

Hey AJ! Nice to run into your work on the internet again. I used serviceman to set up syncthing, but now I want to edit the command, and it seems I'm going to have to reach under syncthing to edit the systemd service directly. Not a huge deal, but would be nice to also have the commands to remove or overwrite a service built-in.

-- Lauren

lahwran avatar Jul 05 '21 19:07 lahwran

I agree.

ryanburnette avatar Jul 11 '21 00:07 ryanburnette

Aj needs to move the old issues here https://git.coolaj86.com/coolaj86/go-serviceman/issues/3

ryanburnette avatar Jul 11 '21 00:07 ryanburnette

Hi Lauren,

I'm not clear on what you mean. Are you saying that you want to be able to list and remove services that weren't added by serviceman?

coolaj86 avatar Jul 11 '21 00:07 coolaj86

no, I'm saying that I want to be able to remove/overwrite services that were added by serviceman, because I don't see a command to do that in the docs or code, unless I missed something.

Relatedly, question I forgot to test the other day and so I'm noting here until I can investigate this myself - is add:

  1. idempotent because it's a noop if the service exists,
  2. idempotent because it's a noop if service CLI config is unchanged,
  3. or not idempotent because eg it always restarts the service

Other musings, to give context as to how I came to use serviceman and create this issue:

The use case here is that ultimately I'd like to be able to use serviceman to install a user service automatically as part of a redo build target, and have that be close to the same development experience as launched-by-the-devtools development. to do that I need a way to overwrite-and-restart the service, which I would then run as something vaguely like:

npx concurrently \
    'watchexec $WATCHEXEC_IGNORE_CONFIG ./reinstall_serviceman.sh' \
    'tailfollow_serviceman_logs.sh'

(but with a lot more package version locking.)

...hmmm, further tangenting off of this, perhaps I should look into how hard it would be to modify webi to install into a virtualenv/node_modules style vendor directory... I'd also love a way to redirect stdio to a file in all cases to make tailfollow_serviceman_logs.sh a simpler script, perhaps just by modifying what I tell serviceman to launch, or maybe modify the systemd config somehow, does systemd support that? hmm...

as you can see, my thoughts on the project that needs this are not very clear right now and I have plenty of workaround options available. sor what it's worth, I see this feature as much as a "todo someday" for myself as it's a feature request for y'all. Triage according to taste, not based on any feeling of urgency from me. good chance I'll just work around it using an approach that looks vaguely like the above sketch. maybe I could even use serviceman to generate the installable thing that goes into publishable packages!

lahwran avatar Jul 12 '21 18:07 lahwran

@lahwran Thanks for the clarification.

I agree. This should have a remove. I'd accept a PR for that, and otherwise I do want to do it... eventually, when I can carve out the time for it.

I believe that add will always rewrite the existing service file and restart the service.

I'd be open for a PR that changes this to check if the file that would be written has the same hash as the existing file and, if so skips restarting. That would also need a --force flag to override.

coolaj86 avatar Jul 17 '21 23:07 coolaj86

I keep wanting this feature. Here's how I do it manually.

sudo systemctl stop myserv
sudo systemctl disable myserv
sudo rm /etc/systemd/system/myserv.service
sudo systemctl daemon-reload

ryanburnette avatar May 14 '23 16:05 ryanburnette

The new version at https://github.com/bnnanet/serviceman has stop and disable.

I believe it's much simpler to use (doesn't require any flags other than --name in the general case), and more featureful.

The transitional v0.9.x is compatible (prints warnings), except that --user is now --agent (rarely used, and often caused issues).

In about a year or so I'll publish v1.0, which will probably do nothing other than drop backwards compatibility with v0.8.x.

I'll finally close this out now.

coolaj86 avatar Dec 12 '24 16:12 coolaj86