I. Resource Control#

This uses Linux’s cgroups mechanism to prevent the service from consuming excessive system resources and affecting other programs.

• MemoryMax=1G
  • Effect: Sets a 1 GiB memory limit for the service’s cgroup.
  • Outcome: If the service cgroup reaches its limit and memory reclaim cannot relieve the pressure, an OOM kill may occur within the group. Here, 1G means 1 GiB.
• CPUQuota=150%
  • Effect: Limits the service to at most 150% CPU usage.
  • Outcome: 100% represents one full CPU core. 150% means the service can saturate one core and use half of a second core (i.e., up to 1.5 CPU cores’ worth of compute).
• TasksMax=200
  • Effect: Limits the service to a maximum of 200 tasks (processes or threads).
  • Outcome: Prevents the service from creating unlimited child processes due to bugs or infinite loops (e.g., fork bomb), which could exhaust system PID resources and crash the system.
• IOWeight=50
  • Effect: Sets the disk I/O priority weight. The default is usually 100.
  • Outcome: Where the device and I/O controller support weighted scheduling, 50 reduces the service’s relative share under contention. It is not a fixed throughput limit or a guarantee that other services remain unaffected.

II. Security & Isolation#

These settings restrict access to filesystems, devices, and sockets to reduce the impact of mistakes and limit some attack paths.

• ProtectSystem=strict
  • Effect: Strictly protects system files.
  • Outcome: Makes the filesystem hierarchy read-only, except for API filesystems and explicitly writable paths. Here, ReadWritePaths keeps the user’s home writable. This mount restriction does not replace kernel security updates.
• PrivateTmp=yes
  • Effect: Provides an independent temporary directory for the service.
  • Outcome: The service sees its own private /tmp and /var/tmp directories. It cannot see or modify files placed in the global /tmp by other users/services, and vice versa. This effectively prevents symlink attacks or data leaks based on temporary files.
• PrivateDevices=yes
  • Effect: Isolates physical devices.
  • Outcome: Provides a private /dev with necessary pseudo-devices such as /dev/null, /dev/zero, and /dev/urandom, restricting direct access to host device nodes. This does not isolate every possible route to hardware access.
• NoNewPrivileges=yes
  • Effect: Restricts acquiring additional privileges by executing another program.
  • Outcome: The service and its descendants cannot gain privileges through setuid/setgid bits or file capabilities during execve(). It does not prevent every escalation path, such as a kernel exploit that directly changes process credentials.
• RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
  • Effect: Restricts the socket address families the service can use.
  • Outcome: Allows creating sockets in these address families:
    • AF_INET: IPv4 network communication
    • AF_INET6: IPv6 network communication
    • AF_UNIX: local UNIX domain sockets (for local IPC)
  • On systems supporting the relevant seccomp filtering, calls to create sockets in other address families are restricted. This reduces attack surface but does not restrict IPv4/IPv6 destinations or revoke sockets inherited or passed to the service.

When creating a new user, just run:

1
adduser <username>
2
systemctl enable --now code-server@<username>

to simultaneously create the corresponding CodeServer service.

Step 1: Start monitoring (handled by the .path file)#

1. The system or administrator starts code-server-restart@yms.path.
2. systemd parses the .path file, replacing %i with yms.
3. PathChanged=/home/yms/.config/code-server/config.yaml: systemd starts quietly listening (using the inotify mechanism) for changes to this specific config.yaml file at the kernel level.

Step 2: Detect change and trigger#

1. The user modifies settings in the CodeServer web interface, or edits config.yaml via the command line and saves.
2. PathChanged detects that the file has been modified and closed (ensuring the write is complete and avoiding reading half-written dirty data).
3. Implicit binding: Because the .path file does not explicitly specify a service to trigger using Unit=, systemd’s default behavior is to trigger the .service file with the same name (without the suffix).
4. systemd then automatically starts code-server-restart@yms.service.

Step 3: Execute the action (handled by the .service file)#

1. systemd executes code-server-restart@yms.service. Again, %i is replaced with yms.
2. Type=oneshot: Tells the system this is not a long-running daemon but a one-shot task. It exits when done.
3. User=root: The restart operation requires higher privileges, so it’s forced to run as root.
4. ExecStart=/usr/local/bin/safe-restart-codeserver.sh <user>: This is the final step in the logic. The system runs the custom shell script as root, passing the username as an argument.

We don’t restart the main daemon directly inside the restart service because CodeServer auto-saves on every edit. There’s a risk that during password changes, a half-edited file might trigger a restart, causing incomplete writes. So we write a script that waits until the file is stable before triggering the restart:

/usr/local/bin/safe-restart-codeserver.sh

1
#!/bin/bash
2
USER_NAME=$1
3
CONFIG_FILE="/home/$USER_NAME/.config/code-server/config.yaml"
4
STAMP_FILE="/tmp/code-server-restart-${USER_NAME}.stamp"
5

6
# 1. Intercept: if stamp file exists and config file is older (or same age) than stamp,
7
#    this trigger is a leftover queued event from systemd – exit
8
if [ -f "$STAMP_FILE" ] && [ "$CONFIG_FILE" -ot "$STAMP_FILE" ]; then
9
    echo "Config hasn't changed since last restart, exiting."
10
    exit 0
11
fi
12

13
# 2. Debounce wait logic (unchanged)
14
while true; do
15
    last_md5=$(md5sum "$CONFIG_FILE")
16
    sleep 5
17
    current_md5=$(md5sum "$CONFIG_FILE")
18

19
    if [ "$last_md5" == "$current_md5" ]; then
20
        # File is stable, perform restart
21
        systemctl restart code-server@$USER_NAME
22

23
        # 3. After successful restart, update the stamp file's mtime
24
        touch "$STAMP_FILE"
25
        break
26
    else
27
        echo "Config file for $USER_NAME is still changing, waiting..."
28
    fi
29
done

The timestamp mechanism prevents multiple pointless restarts. If the config file’s last edit time is earlier than the last restart time, the restart is rejected.

After writing the files, enable the trigger: systemctl enable --now code-server-restart@<username>.path (note it’s .path, not .service). Then try slowly editing the password in the config file via the web interface, and check the logs for something like:

1
○ code-server-restart@lyr.service - Triggered safe restart for lyr
2
     Loaded: loaded (/etc/systemd/system/code-server-restart@.service; disabled; preset: enabled)
3
     Active: inactive (dead) since Sat 2026-06-06 06:43:55 UTC; 29s ago
4
 Invocation: 0bd37fcb6ea44a58870c06b4fde5300c
5
TriggeredBy: ● code-server-restart@lyr.path
6
    Process: 6997 ExecStart=/usr/local/bin/safe-restart-codeserver.sh lyr (code=exited, status=0/SUCCESS)
7
   Main PID: 6997 (code=exited, status=0/SUCCESS)
8
   Mem peak: 2.5M
9
        CPU: 43ms
10

11
Jun 06 06:43:40 CodeServer systemd[1]: Starting code-server-restart@lyr.service - Triggered safe restart for lyr...
12
Jun 06 06:43:45 CodeServer safe-restart-codeserver.sh[6997]: Config file for lyr is still changing, waiting...
13
Jun 06 06:43:50 CodeServer safe-restart-codeserver.sh[6997]: Config file for lyr is still changing, waiting...
14
Jun 06 06:43:55 CodeServer systemd[1]: code-server-restart@lyr.service: Deactivated successfully.
15
Jun 06 06:43:55 CodeServer systemd[1]: Finished code-server-restart@lyr.service - Triggered safe restart for lyr.

After editing stops for 5 seconds, CodeServer will restart, and the new password can be used to log in.