Re: cannot set terminal process group

Re: cannot set terminal process group

[Jonathan de Boyne Pollard]

DGSJ:

> Well, Crtl+C doesn't work, [...]
>
It seems to be the time of year for this question.  I just answered 
another variant of it, complete with daemontools-style chain loading 
tools.  Read the further reading and other questions, too.

* https://unix.stackexchange.com/questions/410318/

* https://unix.stackexchange.com/questions/255385/

* https://unix.stackexchange.com/questions/338214/

cannot set terminal process group

[DGSJ]

Hello,

I didn't pay too much attention to this message displayed after login, 
mainly because everything seems to go well enough.

login:
Password:
-bash: cannot set terminal process group (193): Inappropriate ioctl for device
-bash: no job control in this shell
[ ~ ]#

Well, Crtl+C doesn't work, but until now I could cope with it, but now 
that I'm progressing in the migration I would like to fix it.

I'm using agetty for the ./run file of the service.

/etc/sv/getty-3/run
#!/bin/sh 
exec /sbin/agetty 38400 tty3 linux

And this is the output of ps -fx:

  1 ?     Ss     0:00 runit
192 ?     Ss     0:00 runsvdir -P /service log:...................
193 ?     Ss     0:00  \_ runsv getty-3
201 ?     S      0:00  |   \_ /bin/bash ./run
215 ?     S      0:00  |   |   \_ /usr/local/bin/svlogd -tt /tmp/agetty3
224 ?     S      0:00  |   \_ /bin/login --
285 ?     S      0:00  |       \_ -bash

It seems that bash is expecting PID 193 to be a terminal, but it finds 
runsv instead (maybe due to the effect of exec).

I could change agetty to getty in order for managing the terminal, but 
before I would like to understand the problem and a possible solution.

What is then the reason for that warning and what could be the solution?

Thank you in advance for your cooperation

-- 
-------------------------
Daniel Gutiérrez San José

Re: cannot set terminal process group

[Laurent Bercot]

  Indeed, runit does not run the service as a session leader by default.
runsvdir runs every instance of runsv in a different session, but a
runsv instance runs its service in the same session.
  The workaround, as Jonathan pointed out, is to add "setsid"
(or "chpst -P") to your run script, in the command line that execs into
your daemon.

  Note that s6 runs the service as a session leader by default,
precisely to avoid that minor annoyance. There is no benefit in running
the supervisor processes in a different session from the scanner
process, but there is benefit in running the services in their own
session.

--
  Laurent