Re: Open-iscsi slow boot
I understand your analysis and appreciate your help. I've now posted on a QNAP forum to get help in diagnosis on that side. I'll post the solution here when I find it. R On Thursday, June 27, 2019 at 11:21:45 AM UTC-7, The Lee-Man wrote: > > On Thursday, June 27, 2019 at 11:44:11 AM UTC-4, Randy Broman wrote: >> >> I appreciate your interest, and I've attached a text file which I hope >> is responsive to your request. >> >> R >> >> On Wed, Jun 26, 2019 at 8:55 AM The Lee-Man wrote: >> > >> > On Tuesday, June 25, 2019 at 11:31:03 AM UTC-4, Randy Broman wrote: >> >> >> >> Thanks for your response. I'm using Kubuntu 19.04. I disabled the >> iscsi service and in fact the boot was much faster: >> >> >> >> >> > I'm not understanding what's going on with your system. I suspect >> there's more than just an unused open-iscsi initiator involved here. >> > >> > Do you have any iscsi targets set up? Existing sessions? >> > >> > I downloaded kunbuntu, and open-iscsi.service is enabled by default. >> Can you give me the systemctl status for open-iscsi.service, iscsid.socket, >> and iscsid.service? Also, an "ls" of /etc/iscsi/nodes and >> /sys/class/iscsi_session? >> > >> > And please don't assume that the numbers that "systemd-analyze blame" >> show -- they don't always mean what you think. Can you just please time the >> boot (or reboot) sequence yourself, using the log files? >> > >> > On my test VM, I have iscsid.socket, iscsid.service, and >> open-iscsi.service at their default settings, but I have never discovered >> any targets, so I don't have any history of nodes or sessions. And when I >> run "systemd-analyze blame", iscsi does not show up at all. >> > >> >> > Your error messages make it clear that you are having initiator/target > issues. If you look at the status of the open-iscsi.service unit, you can > see it waits for the target to connect, then times out. Timing out always > adds lots of time to a boot process. > > It seems there is some issue with your "QNAP Target". I cannot help you > with that. But you might want to check there for error messages, if there > is some way to do that. > > > -- 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 open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/e452fddf-5f5b-417f-9900-33e48d487b9e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Open-iscsi slow boot
On Thursday, June 27, 2019 at 11:44:11 AM UTC-4, Randy Broman wrote: > > I appreciate your interest, and I've attached a text file which I hope > is responsive to your request. > > R > > On Wed, Jun 26, 2019 at 8:55 AM The Lee-Man wrote: > > > > On Tuesday, June 25, 2019 at 11:31:03 AM UTC-4, Randy Broman wrote: > >> > >> Thanks for your response. I'm using Kubuntu 19.04. I disabled the iscsi > service and in fact the boot was much faster: > >> > >> > > I'm not understanding what's going on with your system. I suspect > there's more than just an unused open-iscsi initiator involved here. > > > > Do you have any iscsi targets set up? Existing sessions? > > > > I downloaded kunbuntu, and open-iscsi.service is enabled by default. Can > you give me the systemctl status for open-iscsi.service, iscsid.socket, and > iscsid.service? Also, an "ls" of /etc/iscsi/nodes and > /sys/class/iscsi_session? > > > > And please don't assume that the numbers that "systemd-analyze blame" > show -- they don't always mean what you think. Can you just please time the > boot (or reboot) sequence yourself, using the log files? > > > > On my test VM, I have iscsid.socket, iscsid.service, and > open-iscsi.service at their default settings, but I have never discovered > any targets, so I don't have any history of nodes or sessions. And when I > run "systemd-analyze blame", iscsi does not show up at all. > > > > Your error messages make it clear that you are having initiator/target issues. If you look at the status of the open-iscsi.service unit, you can see it waits for the target to connect, then times out. Timing out always adds lots of time to a boot process. It seems there is some issue with your "QNAP Target". I cannot help you with that. But you might want to check there for error messages, if there is some way to do that. -- 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 open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/485a70e6-e456-42d3-ad52-9f1e570cff0a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Open-iscsi slow boot
I appreciate your interest, and I've attached a text file which I hope is responsive to your request. R On Wed, Jun 26, 2019 at 8:55 AM The Lee-Man wrote: > > On Tuesday, June 25, 2019 at 11:31:03 AM UTC-4, Randy Broman wrote: >> >> Thanks for your response. I'm using Kubuntu 19.04. I disabled the iscsi >> service and in fact the boot was much faster: >> >> > I'm not understanding what's going on with your system. I suspect there's > more than just an unused open-iscsi initiator involved here. > > Do you have any iscsi targets set up? Existing sessions? > > I downloaded kunbuntu, and open-iscsi.service is enabled by default. Can you > give me the systemctl status for open-iscsi.service, iscsid.socket, and > iscsid.service? Also, an "ls" of /etc/iscsi/nodes and > /sys/class/iscsi_session? > > And please don't assume that the numbers that "systemd-analyze blame" show -- > they don't always mean what you think. Can you just please time the boot (or > reboot) sequence yourself, using the log files? > > On my test VM, I have iscsid.socket, iscsid.service, and open-iscsi.service > at their default settings, but I have never discovered any targets, so I > don't have any history of nodes or sessions. And when I run "systemd-analyze > blame", iscsi does not show up at all. > > -- > 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/NK2sBOEzSQE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > open-iscsi+unsubscr...@googlegroups.com. > To post to this group, send email to open-iscsi@googlegroups.com. > Visit this group at https://groups.google.com/group/open-iscsi. > To view this discussion on the web visit > https://groups.google.com/d/msgid/open-iscsi/8fe010f4-fc0f-4021-a20e-9d7bdfaf0a76%40googlegroups.com. > 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 open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/CAAixNYGu7RLUwvYZvFV8LzuorUcAXpwjXbuA6PqoeZmDL1rX1g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. > I'm not understanding what's going on with your system. I suspect there's > more than just an unused open-iscsi initiator involved > here. Requested info is below, hopefully I collected the right stuff, if not let me know. I see messages like "no route to host" and "could not log in" (to target), which don't make sense to me, as the QNAP target NAS is continually running, ping-able, and should thus be available, and thus it seems like the initiator is correctly configured as the connection does succeed eventually. Maybe the delay is in the QNAP needing time to wake up upon the requests by the initiator upon it's boot (QNAP uses their own variant of linux, and I can ssh into it and collect info on the QNAP/targets if you can give me guidance on what to collect) > Do you have any iscsi targets set up? Existing sessions? There's one target: $ sudo iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-870 version 2.0-874 Target: iqn.2004-04.com.qnap:ts-473:iscsi.qnapiscsilu.2356fd (non-flash) Current Portal: 192.168.1.30:3260,1 Persistent Portal: 192.168.1.30:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface Initiatorname: iqn.2015-06.world.server:www.server.world Iface IPaddress: 192.168.1.17 Iface HWaddress: Iface Netdev: SID: 1 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE * Timeouts: * Recovery Timeout: 15 Target Reset Timeout: 30 LUN Reset Timeout: 30 Abort Timeout: 15 * CHAP: * username: password: username_in: password_in: Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 262144 MaxXmitDataSegmentLength: 262144 FirstBurstLength: 65536 MaxBurstLength: 262144
