Re: [RFC] example init.d script for tgtd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 22 Oct 2008 11:33:58 +0900
FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote:

> On Wed, 22 Oct 2008 12:50:22 +1100
> "ronnie sahlberg" <ronniesahlberg@xxxxxxxxx> wrote:
> 
> > On Wed, Oct 22, 2008 at 12:47 PM, FUJITA Tomonori
> > <fujita.tomonori@xxxxxxxxxxxxx> wrote:
> > > On Tue, 21 Oct 2008 15:56:17 +0200
> > > Tomasz Chmielewski <mangoo@xxxxxxxx> wrote:
> > >
> > >> FUJITA Tomonori schrieb:
> > >>
> > >> (...)
> > >>
> > >> >> # tgtd ; tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2008-01.....
> > >> >> tgtadm: can't connect to the tgt daemon, Connection refused
> > >> >> tgtadm: can't send the request to the tgt daemon, Transport endpoint is not connected
> > >> >
> > >> > I guess that 'daemon' program works differently from what you did here
> > >> > (that's what I wrote in the previous mail). But I might be wrong since
> > >> > I don't know how 'daemon' program works (Debian doesn't have the program).
> > >> >
> > >> > For your case, this patch helps (you also need the tgtadm patch that
> > >> > I've just sent)?
> > >>
> > >> It helps here.
> > >>
> > >> # tgtd ; tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn....
> > >> # tgt-admin -s
> > >> Target 1: iqn....
> > >>     System information:
> > >>         Driver: iscsi
> > >> (...)
> > >>
> > >> Repeated several times, so it seems like it works.
> > >
> > > Yeah, it should work for your case.
> > >
> > >
> > >> Restarting still needs "sleep 1s" ;)
> > >>
> > >> # tgtd ; tgtadm --op delete --mode system ; tgtd
> > >> (null): iscsi_tcp_init(222) unable to bind server socket, Address already in use
> > >> No available low level driver!
> > >> #
> > >
> > > I guess that there is a way to work around this. But I can't recall
> > > now. I need to check a network programing book.
> > >
> > 
> > setsockopt()
> > SO_REUSEADDR
> 
> Thanks!
> 
> I found that I already use SO_REUSEADDR for iSCSI sockets. :)
> 
> 
>  # tgtd ; tgtadm --op delete --mode system ; tgtd
> 
> 
> I guess, this problem happens in the following way.
> 
> 1. execute `tgtadm --op delete --mode system`
> 2. tgtd sets system_active to zero and notifies tgtadm of the
> completion of the request.
> 3. tgtadm returns and the scripts tries to run tgtd again however tgtd
> still runs (it takes some time until tgtd dies after setting
> system_active to zero).

I don't like this patch since it's a bit hacky but it should work.

Please let me know if someone has a better idea.


diff --git a/usr/tgtadm.c b/usr/tgtadm.c
index ce7eb24..836efaa 100644
--- a/usr/tgtadm.c
+++ b/usr/tgtadm.c
@@ -186,15 +186,13 @@ static int ipc_mgmt_connect(int *fd)
 	       strlen(TGT_IPC_NAMESPACE));
 
 	err = connect(*fd, (struct sockaddr *) &addr, sizeof(addr));
-	if (err < 0) {
-		eprintf("can't connect to the tgt daemon, %m\n");
+	if (err < 0)
 		return errno;
-	}
 
 	return 0;
 }
 
-static int ipc_mgmt_rsp(int fd)
+static int ipc_mgmt_rsp(int fd, struct tgtadm_req *req)
 {
 	struct tgtadm_rsp rsp;
 	int err, rest, len;
@@ -223,6 +221,24 @@ retry:
 		return EINVAL;
 	}
 
+	if (req->mode == MODE_SYSTEM && req->op == OP_DELETE) {
+		while (1) {
+			int __fd, ret;
+			struct timeval tv;
+
+			ret = ipc_mgmt_connect(&__fd);
+			if (ret == ECONNREFUSED)
+				break;
+
+			close(__fd);
+
+			tv.tv_sec = 0;
+			tv.tv_usec = 100 * 1000;
+
+			select(0, NULL, NULL, NULL, &tv);
+		}
+	}
+
 	rest = rsp.len - sizeof(rsp);
 	if (!rest)
 		return 0;
@@ -248,8 +264,10 @@ static int ipc_mgmt_req(struct tgtadm_req *req)
 	int err, fd = 0;
 
 	err = ipc_mgmt_connect(&fd);
-	if (err < 0)
+	if (err < 0) {
+		eprintf("can't connect to the tgt daemon, %m\n");
 		goto out;
+	}
 
 	err = write(fd, (char *) req, req->len);
 	if (err < 0) {
@@ -260,7 +278,7 @@ static int ipc_mgmt_req(struct tgtadm_req *req)
 
 	dprintf("sent to tgtd %d\n", err);
 
-	err = ipc_mgmt_rsp(fd);
+	err = ipc_mgmt_rsp(fd, req);
 out:
 	if (fd > 0)
 		close(fd);
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]

  Powered by Linux