cccb-website-team/kik-website
Watch
0
0
Fork
You've already forked kik-website
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Start the server again when the cleanup job's start was dropped

Browse source 
The task that runs the server ignores a start while it thinks it is still
running, so the cleanup job could stop the server and then fail to start it
again: the site had no shell for forty minutes. The start is now tried three
times, with the processes of the task killed in between.

The job now only counts the established connections when it decides whether
anybody is connected - the server leaves the processes of finished sessions
behind, and they kept it from ever restarting the server. Those processes are
killed with the server, because they hold the runtime and the protected
programs open.

The pacman calls are bounded, so a database lock cannot keep the server down,
and they run before the server is stopped. The exit code of a program started
this way is only available when its handle is taken while it runs, and the
pattern for the files to overwrite has to be quoted, or the runtime expands
it.

Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
Zebreus 2026-10-27 20:36:52 +01:00
commit f4113033ac
1 changed files with 53 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

8
server/README.md
View file

@ -50,8 +50,8 @@ The runtime itself is not among the protected copies. A program and the shell th
runtime DLL, or the program does not run at all - a second copy of it in one process is refused. The login path
therefore uses the one in `/usr/bin`, next to the user's own programs, and the user may replace and upgrade it.
What is protected instead is that it is the one the package says it is: pacman checks the files of `msys2-runtime`,
and the cleanup job puts the package back if it was changed - before it starts the server, which runs as SYSTEM and
would otherwise run code the user of the website wrote.
and the cleanup job puts the package back if it was changed - while the server is stopped, before it starts it
again, because the server runs as SYSTEM and would otherwise run code the user of the website wrote.
`/etc/passwd` (the login shell and home directory) and `/etc/ssh` (the host keys and config) are read-only to the
user as well; everything else in the installation is theirs.
@ -71,6 +71,10 @@ it comes back by itself if it died, it takes over a server that was left behind,
were just restored. A session that is open keeps the port, so a server that is started now could not bind it, and
the job never disturbs a session.
The task that runs the server ignores a start while it thinks it is still running, so a start that is dropped
leaves the site without a shell. The cleanup job therefore tries three times, killing the processes of the task
in between, before it gives up.
The deployment does not restart the server. It runs in a session, and that session keeps the port, so a server that
starts during a deployment cannot bind it. The new configuration and the restored programs therefore take effect
at the next run of the cleanup job, which happens within half an hour.