On Wednesday, February 4, 2015 at 10:44:33 AM UTC-8, Chris Leech wrote: > > On Fri, Jan 30, 2015 at 02:09:54PM -0800, The Lee-Man wrote: > > Hi Mike: > > > > Just a heads up that stopping the open-iscsi iscsid daemon using systemd > > doesn't seem to be working correctly, at least not on SUSE SLE 12. > > > > When I have one or more sessions present, and their startup value is set > to > > "manual", when I try to stop the iscsid service, I get: > > > > # systemctl stop iscsid.service > > Job for iscsid.service canceled. > > That's not the normal service stop message is it? Job canceled? Did > you somehow have a pending start job queued up in systemd even though > iscsid was running? >
No, "Job ... canceled." is systemd-speak for "your request failed". If I remove the "ExecStop=" attribute from the service file I do not get this message, and the "stop" succeeds. > > > And a "ps" shows that iscsid is still running, but under a new process > id. > > And, at times, I see that "iscsiadm -k 0 2" is hung. > > I was going to say that this is about the only problem I haven't run > into with systemd, but it looks like I can hit this (some of the time, > not always or even often) if I loop on socket activation and service > stopping. > > > 2. It looks like the "iscsiadm -k 0" is stopping the iscsi daemon, but > that > > systemd is restarting it! I'm guessing this because (a) I get the > > "cancelled" message, and (b) iscsid is still running, but as a new > process, > > i.e. it's been restarted. > > I'm wondering if it has something to do with the ExecStop command > returning before iscsid actually terminates, although I'm not sure > what's triggering the service restart. > I think you're onto the meat of the problem: the sequencing systemd does between the "ExecStop=" and the command itself. The systemd.service(5) man page says about ExecStop: "...After the commands configured in this option are run, all processes remaining for a service are terminated according to the KillMode= setting (see systemd.kill(5))." So I'm thinking systemd does not like that this command actually stops the service. But this only happens if the service is socket-activated, so it must be the socket service that is restarting iscsid. If I stop iscsid.socket before iscsid.service, this does not happen. But systemd doesn't normally shut things down that way, since iscsid.service depends on iscsid.socket. > > > I thought perhaps the problem was related to running iscsid as a > "simple" > > service, in the foreground, but changing Type to forking and removing > the > > "-f" from the iscsid command line did not change anything. > > That's about the only difference I see from what I have in Fedora/RHEL. > You might also have a different variant of systemd? I really believe there are two long-term solutions to this: 1. find a way to tell systemd that an ExecStop command will actually stop the service, and that's ok. OR 2. Remove the ExecStop command. If there are problems with stopping, deal with them by beefing up the signal handling in iscsid, since that's the method systemd uses to stop such services. > > - Chris > -- 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 open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to email@example.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.