dank/serverAppConfigs
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

SearXNG deploy: do not systemctl enable the generated units

Browse Source 
Quadlet units are generator-managed; systemctl enable fails on them
('transient or generated'). The [Install] WantedBy=default.target in each
.container file is itself the enablement (is-enabled reports 'generated'), and
with user linger on they start at boot. Drop the enable step; daemon-reload and
start are enough.
This commit is contained in:
Frank
2026-08-19 00:05:25 -07:00
parent 06ac2a84cf
commit 9f4c0d4175
1 changed files with 6 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
scripts/deploy-searxng-quadlet.sh
+6 -4
View File
@@ -77,11 +77,13 @@ echo ' Copying quadlet units into ~/.config/containers/systemd/ ...'
mkdir -p ~/.config/containers/systemd
cp ${QDIR}/*.container ${QDIR}/*.network ~/.config/containers/systemd/
echo ' daemon-reload + enable the container units for boot...'
# The .network unit is generator-managed: it cannot be enabled, and it is pulled
# in automatically by the containers that set Wants=/After=searxng-network.service.
echo ' daemon-reload (generates the units)...'
# Quadlet units are generator-managed: systemctl enable fails on them ("transient
# or generated"). The [Install] WantedBy=default.target in each .container file is
# itself the enablement (is-enabled reports "generated"), and with user linger on
# they start at boot. The .network unit is pulled in by the containers that set
# Wants=/After=searxng-network.service. So: daemon-reload, then start.
systemctl --user daemon-reload
systemctl --user enable gluetun.service searxng-valkey.service searxng.service
echo ' Starting in dependency order...'
systemctl --user start searxng-network.service