SLP_Software/slp-modular-cms
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases Wiki Activity

Names su - specifically as a confirmed cause, not just sudo -u

Browse Source 
Traced live on the actual Pi: su - gitea-workflow left XDG_RUNTIME_DIR
unset even with the user manager already running and the bus socket
already there. None of su/sudo -i/sudo -u reliably go through
pam_systemd on Debian - only a real SSH login or sshd itself does,
which is what the deploy workflow already uses.
This commit is contained in:
Sluijsens
2026-07-29 13:15:11 +02:00
parent 6882eda03f
commit 743c173257
2 changed files with 31 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/gitea-deployment-workflow/audit.md
+11
View File
@@ -1367,3 +1367,14 @@ by Infrastructure Design. U5 carries REF-U3-01's Umami origin gate plus FR-21 an
**Context**: OPERATIONS — Deployment Setup, host-setup troubleshooting captured in documentation
---
## Deployment Setup — Confirmed Root Cause: su - Does Not Set XDG_RUNTIME_DIR
**Timestamp**: 2026-07-29T00:20:00Z
**User Input**: "oh, ik logde elke keer in met `su - gitea-workflow`. Is dat het probleem geweest?"
**AI Response**: "Confirmed: su - (and sudo -i -u, and sudo -u) don't reliably invoke pam_systemd on Debian-based systems, since /etc/pam.d/su typically lacks that module unlike /etc/pam.d/sshd. Real SSH login as the user works correctly; a manual `export XDG_RUNTIME_DIR=/run/user/$(id -u)` also fixes it per-shell. Confirmed this does not affect the real deploy pipeline, which always connects via genuine SSH. Rewrote deployment-instructions.md's troubleshooting note to name su - explicitly as a confirmed-in-practice cause, not just a theoretical one."
**Context**: OPERATIONS — Deployment Setup, host-setup troubleshooting root cause confirmed and documented
---