3

I'm trying to use systemctl to launch a process in a new, shared, tmux session. I'm pretty sure my tmux command is all set:

  • I have the socket path set with a shared group.
  • the service is executing under a user that's a member of the group
  • I've tested from the CLI and it works; I can attach with another account.

The command looks like this:

tmux -S /tmp/tmux/sharedsesh new-session -s sharedsesh -d "/usr/bin/java server.jar"

However, when I put it in a new systemctl unit, I'm getting an error: "tmux: unknown option -- S". Since this is an uppercase S, I'm wondering if that means it doesn't have access to sockets or something?

Unit file:

[Unit]
After=network.target

[Service]
WorkingDirectory=/srv/workspace
PrivateUsers=true
User=servhost
Group=servhost
ProtectSystem=full
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true

ExecStart=/usr/bin/tmux -S /tmp/tmux/sharedsesh new-session -s sharedsesh -d "/usr/bin/java server.jar"

I've looked at the security directives under Service, but in the end I'm left with the error. And, I'm still wondering why it doesn't know about the S option - I'm running the same command as when I do it on the console, so why's it unknown?

== Edit =========

Ok, like so often is the case, just after posting I found my issue.

In fact my ExecStart line is just fine - the error was from my subsequent controls, likely the next one: (bad syntax)

ExecReload=/usr/bin/tmux send-keys -S /tmp/tmux/sharedsesh "reload" Enter
                         ^ -S should be here               ^ send-keys here

In my defense, I was getting the error messages from journalctl which did not show line numbers. Also, I didn't expect it because I didn't expect those to run.

Which leads to my next issue: now that I've fixed the syntax, it's clear that the service is stopping immediately after starting (and Stopping timed out. Terminating. error to boot).

I guess my real issue is something wrong in my Unit file? Or does systemd not like the way tmux detaches? Or something else?

8
  • 1
    Why on earth are you trying to run tmux this way, or at all? Just run your service directly. Commented Sep 6, 2020 at 17:56
  • because the server I'm running needs an active session
    – end-user
    Commented Sep 6, 2020 at 17:58
  • Interesting question, I'd like to see an answer to use it also. In the meantime I suggest you to use nohup. It might help you accomplish what you need. I use it to start some servers without daemon, for example, nohup /usr/bin/java -jar server.jar 2>&1 > console.out &. Better put the line java -jar server.jar in a shell script, for example start.sh and then call this through nohup due to many spaces.
    – Krackout
    Commented Sep 6, 2020 at 18:51
  • 2
    You should fix the server, then, rather than trying this nasty hackery. Commented Sep 6, 2020 at 19:39
  • 1
    I appreciate that, in a perfect world, servers would be written to accommodate a daemon mode, and that development would be continuous and responsive. However, this is the situation I'm dealing with and I'm looking for guidance in using these tools. Honestly, I'm trying to tackle this with tmux because it was suggested that it was better than screen - which I had working.
    – end-user
    Commented Sep 6, 2020 at 21:24

1 Answer 1

1

It appears the answer is I needed a Type=forking setting in the Service stanza. Next I have to figure out how to let the service manager know that it was stopped intentionally (when the session terminates, the control process thinks it was a crash). But at least the tmux server and session are persisting and I can connect with a different user.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .