Remix.run Logo
mikepurvis 5 days ago

For daemonizing a single service, I agree it's silly. I think the argument becomes more complex when you have a whole group of services. The "proper" way for that involves a systemd unit for each process, and then if you want the dashboard experience you still have to launch all the panes and get each one tailing the respective unit journals.

It's tougher to make the case there that systemd units are "worth it", particularly given the other ergonomic benefits of a pure tmux solution, such as being able to ctrl-c a pane and trivially re-launch it.

And once you're launching services in a container, that's another world again, since systemd in that case is quite a bit worse and probably wants CAP_ADMIN.

hnlmorg 5 days ago | parent [-]

> For daemonizing a single service, I agree it's silly. I think the argument becomes more complex when you have a whole group of service

I dont agree that a bunch of services makes things harder if it’s already easier as one service. The set up here is linear in effort. Plus, if anything, being able to restart the host and have all services automatically come up makes systemd much more convenient.

> and then if you want the dashboard experience you still have to launch all the panes and get each one tailing the respective unit journals.

logs are a literal one liner with systemd. Though if you care about dashboards then you should be exporting your logs to a proper observability platform instead of SSHing into your service.

> such as being able to ctrl-c a pane and trivially re-launch it.

  systemd restart …
Is less effort than

  tmux attach …
  [prefix]+w (select window)
  ctrl+c
  [up]
  [return]
> And once you're launching services in a container, that's another world again, since systemd in that case is quite a bit worse and probably wants CAP_ADMIN.

If you’re launching a service in a container then you don’t need either systemd nor tmux in that container because the container itself provides all that scaffolding for you.

Whether it’s Docker/podman, LXC, FreeBSD jails, Solaris Zones, etc, you just set your service to be the entry point of that container.

Docker makes this even easier still with a literal directive called “entrypoint”.

Trying to start services using tmux inside of a container is massively more effort than calling it directly from the entrypoint.

———

I do get the appeal of using tmux for these usages. I honestly do. And if your services are constant in flux, for example inference where you’re constantly tweaking parameters then tmux does make sense (a proper ML pipeline makes more sense, but that requires knowledgable MLOps to build). However for anything consistent, the effort in doing things “properly” is usually less than you think it is.