On Nov 23, 2016, at 12:39 AM, Ulrich Windl <[email protected]> wrote: > >>>> <[email protected]> schrieb am 22.11.2016 um 23:42 in Nachricht > <[email protected]>: > [...] >> The second patch modifies iscsid to treat a >> SIGTERM just like it had received the "immediate >> stop" command from iscsiadm (via the "-k" >> option), simplifying the shutdown of iscsid so >> that it no longer requires IPC communications. > > Good common practice see to perform an orderly (clean) shutdown on first > receipt of SIGTERM; if another SIGTERM arrives a few seconds (time depending > on the application) later, a more immediate shutdown should be attempted > (still trying to be as clean as possible).
In this case, I think this is overkill since systemd is already managing shutdown escalation for us. Systemd will, by default, send a SIGTERM. I have configured it to send that SIGTERM to the main process only by setting KillMode=mixed in the unit file. Systemd will then send SIGKILL to all the processes in the process group after its default stop timeout. This timeout defaults to 90 seconds but can of course be configured separately if desired for iscsid. I believe the best approach may be to handle it exactly like the IPC request for shutdown is handled, i.e. set the “exit the polling loop” flag, then return. If this approach does not work within the timeout period a SIGKILL is going to be received. > > I had implemented such a pattern in a network server, and I'll use it for an > example here (forgive!): > 1st signal prevents accepting new connections; server will shut down if all > connections are gone > 2nd signal will shutdown connections if current requests have been answered > 3rd signal will terminate active connections (those who transfer data) (i.e. > after a recv/send) > 4th signal will terminate connections blocked on sending or receiving data > (i.e. kill an "active" recv/send) > So eventually the server will arrive in the "1st signal received state" > eventually... > > Regards, > Ulrich > >> >> Hannes Reinecke (1): >> Use timeout when waiting for responses from iscsid >> >> Lee Duncan (1): >> iscsid: treat SIGTERM like "iscsiadm -k 0". >> >> usr/config.h | 1 + >> usr/discovery.c | 16 +++++++------- >> usr/host.c | 2 +- >> usr/iscsi_sysfs.c | 1 + >> usr/iscsiadm.c | 12 ++++++----- >> usr/iscsid.c | 29 +++++++++++++++----------- >> usr/iscsid_req.c | 52 >> +++++++++++++++++++++++++++++++++++++--------- >> usr/iscsid_req.h | 15 +++++++------ >> usr/iscsistart.c | 4 ++-- >> usr/session_info.c | 14 +++++++------ >> usr/session_info.h | 5 +++-- >> 12 files changed, 99 insertions(+), 53 deletions(-) >> >> -- >> 1.8.5.6 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "open-iscsi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/open-iscsi. >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "open-iscsi" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/open-iscsi/bwoKUjj6cdk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/open-iscsi. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
