Using -N argument with a terminal multiplexer in a TTY-less environment

[blm768]

While playing with dtach in a Docker container, I found that dtach -N <some socket> <some command> seems to exit silently when it's invoked in an environment which has no terminal (which is Docker's default) but works fine if I make Docker allocate a terminal. That would make sense for the -c mode, but I'd imagine that -N could theoretically work just fine when dtach is started in a "terminal-less" environment since it creates its own PTY for the command and never attaches to it. Is this just a side effect of how dtach currently handles terminals, or is there a fundamental limitation in the Linux APIs that would prevent dtach from functioning correctly in a terminal-less environment without daemonizing?

It's an easy enough fix in my own project to just allocate a terminal, but I figured I'd mention it in case you thought it was worth looking at eventually.

[rdebath]

I just tried this:

$ setsid -w nohup env -i dtach -N /home/robert/tmp/.dt16 -Ez bash >/dev/null </dev/null 2>&1

It creates a shell and waits. The dtach process is not associated with any terminal, has it's stdio pointing at /dev/null and has a completely empty environment. I also tried running it from init:

P2:23:respawn:/bin/su robert -c 'dtach -N /home/robert/tmp/.dt16 -Ez bash'

So ... works for me.

Any more details? Traces, errors?

[blm768]

Huh. I thought I'd managed to rule out the issue being in the script I was running, but apparently not. I can reproduce it if I have dtach try to start either dvtm or tmux, though, so the real issue seems to be that a terminal multiplexer won't run inside a dtach -N session when dtach has no parent terminal. setsid -w nohup env -i dtach -N /tmp/dtsession -Ez dvtm >/dev/null </dev/null 2>&1 is exiting with code 1 on my machine.

[rdebath]

Humm, tmux seems to work fine, as long as I add TERM=$TERM to the environment list. OTOH: dvtm appears to be a bit crash happy, maybe it needs something else too.

[blm768]

Right; I forgot about $TERM. That makes sense. In that case, I guess there's really no issue with dtach then, unless you think it should be setting $TERM for some reason. But since it's designed to be terminal-agnostic anyway, I guess that wouldn't make much sense.

[anarcat]

this is also a problem when running dtach under a systemd session and drove me up the walll... I found this discussion:

https://stackoverflow.com/questions/34808956/dtach-in-systemd-service-file

... which seem to say that chvt is required before this works, and a tty needs to be allocated.

... which makes no sense to me: the whole point of this thing is to have no terminal available in the first place.

it would be great if this could be started without any TTY.

[anarcat]

actually, nevermind - i was able to run this simply by adding TERM:

[Unit]
Description=IRC screen session
After=network.target

[Service]
Type=simple
Environment="TERM=xterm"
User=%i
ExecStart=/bin/sh -c 'exec /usr/bin/dtach -N %t/user/$(id -u)/dtach-irssi.socket irssi -c /dev/null'
ExecStop=/bin/sh -c 'echo /quit | exec /usr/bin/dtach -a %t/user/$(id -u)/dtach-irssi.socket'

[Install]
WantedBy=multi-user.target