Hello, doing some regression test on a kvm cluster I had to run the Open-iSCSI initiator (iscsid) and tgtd on the same machine. This brings up these to issues... 1. Logging of iscsd and tgtd broken But this breaks logging of both iscsd and tgtd because they both run the logging semaphore with the same unix ipc key 0x000000a7 (I think the reason is that the logging code from one project is reused in the other project). The error messages found in syslog are: tgtd: semop up failed iscsid: semop down failed 22 2. IPC Namespace Socket in /tmp I suggest strongly to move the ipc communication socket to /var/run to avoid the socket file is accidentally deleted by admins or cron system maintenance scripts. I think it is also more FHS conform this way. A test case for the breakage of logging facility can found in this redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=676804 And this is my suggested patch to fix these issues: -----------------------------------%<-------------------------------------------- --- tgt-1.0.14.ori/usr/log.c 2011-03-01 12:53:45.000000000 +0100 +++ tgt-1.0.14/usr/log.c 2011-03-03 16:13:53.758746516 +0100 @@ -33,7 +33,7 @@ #include "log.h" -#define SEMKEY 0xA7L +#define SEMKEY 0x54475444L /* TGTD */ #define LOGDBG 0 #if LOGDBG diff -Naur tgt-1.0.14.ori/usr/tgtadm.h tgt-1.0.14/usr/tgtadm.h --- tgt-1.0.14.ori/usr/tgtadm.h 2011-03-01 12:53:45.000000000 +0100 +++ tgt-1.0.14/usr/tgtadm.h 2011-03-03 16:14:01.612496609 +0100 @@ -1,7 +1,7 @@ #ifndef TGTADM_H #define TGTADM_H -#define TGT_IPC_NAMESPACE "/tmp/.TGT_IPC_ABSTRACT_NAMESPACE" +#define TGT_IPC_NAMESPACE "/var/run/tgtd.ipc_abstract_namespace" #define TGT_LLD_NAME_LEN 64 #define GLOBAL_TID (~0U) ----------------------------------->%-------------------------------------------- Kind Regards, Roland -- Roland.Friedwagner@xxxxxxxx Phone: +43 1 31336 5377 IT Services - WU (Vienna University of Economics and Business) -- 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
