Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Normally I'd stay away from job control posix APIs - but since HyperQueue is a job control system, it might be appropriate if the worker was a session leader. If it dies than all its subprocesses would receive SIGHUP - which is fatal by default.

Generally you'd use this functionality to implement something like sshd or an interactive shell. HQ seems roughly analogous.

https://notes.shichao.io/apue/ch9/#sessions



I do use setsid when spawning the children (I omitted it from the post, but I set it in the dsme pre_exec call where I configure DEATHSIG) but they don't receive any signal, IIRC. Or if they do, it does not seem to be propagated to their children.


Calling setsid in pre_exec isn't exactly correct, you'd do this to daemonize a process in order to prevent it from getting signals from the process which spawned you exited or its terminal disconnected.

If you read exit(3) you'll see that you also need a controlling terminal for the kernel to send SIGHUP to the processes in your foreground process group.

In python it'd look roughly like:

  master, slave = os.openpty()

  # ensure we can call setsid successfully

  try:

    pid = os.fork()

    if pid > 0:

      os.close(master)

      os.close(slave)

      sys.exit(0)

  finally:

    sys.exit(1)

  os.setsid()
  # we are now session leader and process group leader

  fcntl.ioctl(master, termios.TIOCSCTTY, 0)
  # we now have a controlling pty - closing master will send us a SIGHUP

  os.close(slave)

  # go start spawning subprocesses - if _this_ process is killed, they will receive SIGHUPs. Unless they take themselves out of your session or the foreground process group.


Yeah I suspect there may be a solution involving setsid




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: