You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(after manually fixing #642) fails with the following error:
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.
The text was updated successfully, but these errors were encountered:
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 #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.
The text was updated successfully, but these errors were encountered: