2024-09-11 18:14:49.330 [8718] main/129/remote_control/127.0.0.1:49356 evio.c:241 E> SocketError: unlink, called on fd 31, aka unix/:(socket), peer of unix/:/home/moiseevgeorgy/Development/github/tarantool/cluster-federation/example/tarantool2_to_tarantool3/instan: Address already in use
2024-09-11 18:14:49.330 [8718] main/129/remote_control/127.0.0.1:49356 F> can't initialize storage: unlink, called on fd 31, aka unix/:(socket), peer of unix/:/home/moiseevgeorgy/Development/github/tarantool/cluster-federation/example/tarantool2_to_tarantool3/instan: Address already in use
Btw, it seems that 4 out of 5 instances fail with this error and the remaining one fails after unsuccessful replication connect, so it is possible that some path is truncated from the tail and reused by tt/cartridge-cli/
cartridge module.
Trying to start the same app with cartridge-cli results in
Failed to start: Failed to build notify socket: Failed to bind socket: listen unixgram /home/moiseevgeorgy/Development/github/tarantool/cluster-federation/example/tarantool2_to_tarantool3/instances.enabled/cluster1/tmp/run/cluster1.s2-replica.notify: bind: invalid argument. Probably socket path exceeds UNIX_PATH_MAX limit
So it seems that basic pipeline doesn't work if path is too long. It is possible that the reason of the issue is either cartridge-cli or cartridge module itself. Still, even if that's the case and it cannot be fixed in tt, it would be nice to fast-fail and do not try to provide half-working workarounds for cartridge instances.
I have created a simple cartridge app nested too deep in my file structure (see https://github.com/tarantool/cluster-federation/pull/207).
is successful, while
(after manually fixing https://github.com/tarantool/tt/issues/642) fails with the following error:
Btw, it seems that 4 out of 5 instances fail with this error and the remaining one fails after unsuccessful replication connect, so it is possible that some path is truncated from the tail and reused by tt/cartridge-cli/ cartridge module.
Trying to start the same app with cartridge-cli results in
So it seems that basic pipeline doesn't work if path is too long. It is possible that the reason of the issue is either cartridge-cli or cartridge module itself. Still, even if that's the case and it cannot be fixed in tt, it would be nice to fast-fail and do not try to provide half-working workarounds for cartridge instances.