Preserve systemd provided socket after shutdown

[frankli0324]

Description

I struggle to understand why gitea unlinks the socket file on shutdown (L171):

gitea/modules/graceful/net_unix.go

Lines 166 to 174 in a701fd3

	for i, l := range providedListeners {
	if isSameAddr(l.Addr(), address) {
	providedListeners = append(providedListeners[:i], providedListeners[i+1:]...)
	activeListeners = append(activeListeners, l)
	unixListener := l.(*net.UnixListener)
	unixListener.SetUnlinkOnClose(true)
	return unixListener, nil
	}
	}

I believe this is unwanted behavior since it breaks systemctl restart gitea when using socket activation.

Gitea Version

a701fd3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

# gitea.service
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target

Wants=postgresql.service
After=postgresql.service

After=gitea.socket
Requires=gitea.socket

[Service]
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea --config /etc/gitea/app.ini --custom-path /pool/git/custom --work-path /var/lib/gitea/ web
Restart=always
Environment=USER=git

[Install]
WantedBy=multi-user.target

# gitea.socket
[Unit]
Description=Gitea Web Socket

[Socket]
ListenStream=/run/gitea/gitea.sock
SocketMode=0666
SocketUser=git
SocketGroup=git

[Install]
WantedBy=sockets.target

Database

PostgreSQL

[zeripath]

Have you tried using kill -1 to restart gitea?

[frankli0324]

Have you tried using kill -1 to restart gitea?

I could, but why?
yes it indeed (maybe, haven't tried) reloads the gitea service without entirely shutting it down, but I believe that's irrelevant to what I'm saying here...

[frankli0324]

from what I learned, SetUnlinkOnClose was designed exactly for preserving the socket file created by systemd by the golang team.

a reference from golang/go#11826 (comment):

if the UnixListener was not responsible for creating the socket file, it should not unlink the socket file on Close.

[silverwind]

Isn't it normal to unlink a inactive socket, indicating it is not available? What other options are there? chmod 000?

[frankli0324]

Set chmod 000?

Leave it alone.

https://www.freedesktop.org/software/systemd/man/systemd.socket.html
in short, systemd provides always active socket, and starts the service on connection if not started. both the creation and destruction of the socket file SHOULD be handled solely by systemd.

again,

if the UnixListener was not responsible for creating the socket file, it should not unlink the socket file on Close.

[silverwind]

Interesting, yeah they mention it multiple times on that link:

A daemon listening on an AF_UNIX socket may, but does not need to, call close(2) on the received socket before exiting. However, it must not unlink the socket from a file system.

Unrelated to gitea, but normally, what I do in my apps is unlink,create and chmod 666 a socket on start, and do nothing with it on shutdown.

[frankli0324]

further explanation on how it breaks "systemctl restart":

• gitea.socket activates, systemd creates ipc file
• gitea.service activates, listens on the ipc file sysd just created
• invoke systemctl restart
• gitea.service deactivates, deleting the ipc file
• gitea.service activates, failing to find the appropriate ipc file to listen on

under such circumstances, users would have to first restart gitea.socket, then gitea.service. moreover, the gitea.service can't be automatically activated on incoming request, which is what systemd.socket is designed for.

[frankli0324]

Unrelated to gitea, but normally, what I do in my apps is unlink,create and chmod 666 a socket on start, and do nothing with it on shutdown.

no, this is not about using ipc file, this is about using systemd.socket. it's two seperate(basically) things to consider.
in the code context I originally listed, google about LISTEN_FDS, see what getProvidedFDs does.

of course a socket file would ultimately be unlinked. but in this case, shouldn't be done by application. it happens when user explicitly stops gitea.socket, not gitea.service.

[frankli0324]

any thoughts?