I’ve seen people use this approach (and screen too) but personally I hate it for anything other than services that are interactive but you want detachable. Eg long running installs.

All the other examples I’ve seen where people have used it as a shortcut for daemonizing a service, it’s felt like just as much effort as writing a systemd service file.

I guess I could forgive people more back in the days of sysv-style initd. Writing those shell scripts was seldom fun. But with systemd, it’s literally a 5 minute task. And I say that as someone who dislikes numerous decisions made regarding the approach systemd takes.

▲ mikepurvis 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 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.