When I run
dbus-run-session sway |& s6-log -b -- n3 s2000000 T ~/.var/log/sway
in tty1 and exit sway via
swaymsg exit
, the s6-log process for logging the sway program doesn’t seem to exit, while dbus-run-session has exited, though (I checked that via another tty). Does somebody have an idea why s6-log doesn’t exit?
>Does somebody have an idea why s6-log doesn’t exit?
The binary itself or why it isn't started in the pipe process?
s6-log the binary itself.
s6-log does start for me, I can see log contents in ~/.var/log/sway/current
I'm guessing it's due to processes spawned by
sway being kept alive after it closes.
s6-log's stdin might be still connected to their stdout/err.
For example, this s6-log invocation will hang the terminal for 6 seconds despite the
background command exiting immediately and the shell not being aware of the spawned
sleep command (you can confirm with
pstree):
background -d -- sleep 6 "" | s6-log ~/.var/test
Also, are you sure sway's s6-log is the one hanging? There's multitude of s6-log's in any s6 system, and if your tty
shows a prompt after exiting sway, it's likely not sway's logger.
Yes. I couldn’t see a prompt after exiting sway.
Ohhh, I wasn’t really aware that this is how it works, though it sounds logical. TIL. Also, this was the root of the issue, so thanks! I just fixed it and now everything works fine. Also thanks for the example!
>I'm guessing it's due to processes spawned by sway being kept alive after it closes.
The process itself or their file descriptors?
In my case it was both, I guess. Processes were being kept alive, and therefore also their file descriptors.
The file descriptors. Mentioning just the processes was an oversimplification, but it hints at the most likely solution.
Technically you can have the processes close/redirect the stderr and stdout (so s6-log's lifetime doesn't depend on theirs anymore) or send the fd's via sockets to processes sway didn't spawn, but that's something very few do.