Steffen Nurpmeso wrote: > Well ok, thinking about this for more than just five minutes > (sorry) i think care should be taken to cause graceful loop wakeup > in any case. I think the lack of feedback about removal success/failure inherent with signals is problematic. > Since _i think_ the poll(2) will not immediately tick due to > SA_RESTART if the "timeout" parameter is not -1, signal(7) on Linux says: "Which of these two behaviors occurs depends on the interface and whether or not the signal handler was established using the SA_RESTART flag (see sigaction(2)). The details vary across UNIX systems; below, the details for Linux." "The details vary across UNIX systems" suggests that you may need to do research on this. My signal(7) later says: "The following interfaces are never restarted after being interrupted by a signal handler, regardless of the use of SA_RESTART; they always fail with the error EINTR when interrupted by a signal handler: ... * File descriptor multiplexing interfaces: ... poll(2) ..." - for Linux. > add a few lines of code which create a socket(2), and perform > a non-blocking connect(2) to the agent socket, followed by an > immediate close(2). There's no error handling after socket(), which is a problem in itself but also ties into the feedback problem. Since this is intended to be a security feature there really needs to be some feedback, making direct interaction with the agents look a lot better, with the significant additional advantage of needing zero new agent code. //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
