Race condition on TCMU_CMD_ADDED_DEVICE

[bno1]

Hello,

I was playing with tcmu-runner and the example handlers and I noticed that if I run tcmu-synthesizer and try to add a user:syn device in targetcli it sometimes fails with UserBackedStorageObject creation failed. Could this be caused by tcmu-runner because it replies to TCMU_CMD_ADDED_DEVICE before tcmu-synthesizer [1]?

[1] https://github.com/open-iscsi/tcmu-runner/blob/master/libtcmu.c#L217-L242

[mikechristie]

Do you have the tcmu-runner daemon and tcmu-synthesizer running at the same time?

If so, then I'm not sure what could happen. It's not supported to have multiple daemons. You will fail like you saw. I think this patch:

#519

fixes that issue, but I think there was some more bugs, so I never got around to merging that patch.

Is this something you need to support? If so, test out that patch and feel free to send patches.

[bno1]

I think that pull request breaks stuff if no daemon has a handler for the added device. I think it would break what this PR tried to solve: #177.

Anyway, if multiple daemons are not supported, how does tcmu-synthesizer work with targetcli? It tries to register the handler with tcmu-runner over dbus, so I assumed that this is a valid use case. Also, if multiple daemons are not supported, then tcmulib_register shouldn't even exist.

If this is the case, then can you please add a disclaimer in the readme and tcmu-synthesizer explaining this so people don't waste their time trying this like I did.

Writing your own tcmu daemon is appealing because some applications are too big or complex to be contained in a tcmu-runner plugin, and libtcmu doesn't copy memory between the kernel and the handler, so I'm not the first or the last person to think of writing their own daemon.