El jue, 3 dic 2020 a las 13:47, Laurent Bercot escribió: > > I have previously added the "nosetsid" feature to s6-supervise, to > address the issue: [...]. So when people want to manually > test a supervision tree, they can have nosetsid files in their test > service directories, and ^C will send a SIGINT to all the processes > including the services, so everything will die, which is what they > want. > [...] > Hence, my question to users: do you have a *valid* reason to use > nosetsid files in your service directories?
I don't know if it is a valid reason, so I'll just tell what I remember using these files for, and you judge :) I happen to be one of those people who test service directories and s6-rc service definitions by running s6-svscan in a terminal using 's6-svscan &' (and then s6-rc-init with a live state directory that is not /run/s6-rc, and lots of -l options), and tearing down the supervision tree using 's6-svscanctl -t .'. So no Ctrl + C in my case. I remember occasionally using 'nosetsid' files for the convenience of being able to redirect the output of 'run' and 'finish' to /dev/tty (the controlling terminal of the shell I used to run s6-svscan) so that I could see certain messages during tests in which s6-svscan had its stdout & stderr redirected to a logger (typically, for emulating an s6-linux-init-like s6-svscan-as-process-1 scenario). I think it was for doing something like foreground { redirfd -w 1 /dev/tty echo "Some message I want displayed on my terminal" } Having the supervised processes become session leaders meant that they lost the controlling terminal, which, for X terminals, would be some random special file in the devpts filesystem. Redirecting to /dev/tty would not work in that case. Granted, it is a rather obscure usage, and not a frequent one in my case, but your mentioning of notsetsid files triggered the memory, so I thought I'd mention that. G.