Socket creation

[mira-miracoli]

We tried the new version (2.1.3) but encountered a problem with the socket creation: hardcoded in the role, the sock will be created in /etc/systemd/system/tiaas.socket, but by default, the role references with tiaas_socket: /run/tiaas.sock.
We solved the problem by creating a symlink ln -s /run/tiaas.sock /etc/systemd/system/tiaas.socket
Without the symlink, it failed due to missing permission (systemd/system is root) and the tiaas2 user has no access.

Obviously, a quick fix would be to hardcode this symlink creation, but I don't know if this is a clean solution.

A smaller, second error was, that we still had tiaas_info.domain: "https://usegalaxy.eu" instead of "usegalaxy.eu", so the ALLOWED_HOSTS failed.

[mira-miracoli]

Update: The symlink we created was overwritten by the systemd tiaas.socket. So this issue seems to be solved. What I still wonder about is why the role did not work for us from the beginning. Tiaas showed a permission error for the socket. I will redeploy it on monday and update here what I observe

[hexylena]

hardcoded in the role, the sock will be created in /etc/systemd/system/tiaas.socket,

So there's also two sockets which is confusing right, there's a systemd ".socket" file which must end in .socket, and isn't actually a socket, it's a text file with the instructions to create a socket, and is associaed with the tiaas.service file.

That .socket file should point to /run/tiaas.sock (named .sock to decrease confusion) which actually is a unix socket.

A symlink should not be required, all the .socket file does is say "look in /run/tiaas.sock for the socket when systemd is handling service startup, and that any requests going to /run/tiaas.sock should trigger starting of the tiaas.service unit. See ListenStream for some very wordy description.

A smaller, second error was, that we still had tiaas_info.domain: "https://usegalaxy.eu" instead of "usegalaxy.eu", so the ALLOWED_HOSTS failed.

yeah thats my fault sorry, forgot to clean that up. We didn't list it in the upgrade instructions as eu was the only one doing it.

[mira-miracoli]

Thank you for the explanation, @hexylena I think we can close the issue!

[mira-miracoli]

So I tried to run the role without touching the tiaas_socket vaiable, but it did not work until I changed it only in the tiaas.service file to /etc/systemd/system/tiaas.socket all the rest I kept on /run/tiaas.sock

[hexylena]

Ahhh now that makes more sense.

[hexylena]

Sockets=
Specifies the name of the socket units this service shall inherit socket file descriptors from when the service is started. Normally, it should not be necessary to use this setting, as all socket file descriptors whose unit shares the same name as the service (subject to the different unit name suffix of course) are passed to the spawned process.

Note that the same socket file descriptors may be passed to multiple processes simultaneously. Also note that a different service may be activated on incoming socket traffic than the one which is ultimately configured to inherit the socket file descriptors. Or, in other words: the Service= setting of .socket units does not have to match the inverse of the Sockets= setting of the .service it refers to.

This option may appear more than once, in which case the list of socket units is merged. Note that once set, clearing the list of sockets again (for example, by assigning the empty string to this option) is not supported.

[hexylena]

socket units being the keyword. @mira-miracoli do you want to PR a fix for that? I'll merge it.