DAW/furt

Fork 0

Service-Management: pexp-Pattern durch PID-File ersetzen #100

New issue

Closed

opened 2025-09-02 18:58:38 +02:00 by michael · 2 comments

michael commented

2025-09-02 18:58:38 +02:00

Owner

Problem

Das aktuelle Service-Management verwendet pexp-Pattern die unzuverlässig und unsicher sind.

werner-Testing Erkenntnisse:

furt läuft stabil und funktionsfähig
rcctl check furt zeigt (failed) obwohl Service läuft
pexp-Pattern /usr/local/bin/lua src/main.lua.* matcht nicht den tatsächlichen Process
Tatsächlicher Process: lua src/main.lua (lua51)

pexp-Pattern Probleme

1. Platform-spezifische Unterschiede

# OpenBSD ps aux:
lua src/main.lua (lua51)

# Linux ps aux: 
/usr/bin/lua5.1 src/main.lua

# Arch Linux ps aux:
/usr/bin/lua src/main.lua

Ein Pattern funktioniert nicht überall.

2. Security-Risiken

# Aktuelles Pattern:
pexp="lua src/main.lua.*"

# Matcht JEDEN Lua-Service mit src/main.lua:
_furt    12345  lua src/main.lua        # furt
_other   67890  lua src/main.lua        # anderes Programm
_app     11111  lua src/main.lua        # noch ein Service

# rcctl stop furt killt ALLE!

3. Multi-Instance Probleme

Verschiedene furt-Instanzen auf verschiedenen Ports
Development vs Production parallel
Keine eindeutige Identifikation möglich

4. Maintenance-Overhead

Pattern muss für jeden OS angepasst werden
Debugging schwierig (welcher Process wird gematcht?)
Fragile Implementation

Lösung: PID-File Service-Management

Warum PID-Files besser sind

Eindeutigkeit: Eine PID gehört exakt einem Process
Sicherheit: Kann nur den korrekten Process killen
Platform-unabhängig: PIDs funktionieren überall gleich
Standard-Pattern: Etablierte Unix/Linux-Konvention
Multi-Instance-fähig: Verschiedene PID-Files möglich

Implementation

1. start.sh erweitern

Service-Detection + PID-File:

# Service vs Interactive Detection
if [ ! -t 0 ] || [ ! -t 1 ]; then
    # Service mode - Background + PID-File
    "$LUA_COMMAND" src/main.lua &
    PID=$!
    echo $PID > /var/run/furt.pid
    echo "Furt started (PID: $PID)"
else
    # Interactive mode - Foreground (kein PID-File)
    exec "$LUA_COMMAND" src/main.lua
fi

2. rc.d Script umstellen

OpenBSD rc.d ohne pexp:

#!/bin/ksh

daemon="/usr/local/share/furt/scripts/start.sh"
daemon_user="_furt"
daemon_cwd="/usr/local/share/furt" 
daemon_flags="start"

# PID-File basierte Funktionen
rc_check() {
    [ -f /var/run/furt.pid ] && kill -0 $(cat /var/run/furt.pid) 2>/dev/null
}

rc_stop() {
    if [ -f /var/run/furt.pid ]; then
        kill $(cat /var/run/furt.pid) 2>/dev/null
        rm -f /var/run/furt.pid
    fi
}

. /etc/rc.d/rc.subr

rc_cmd $1

3. Systemd Service (Linux)

Native PID-File Support:

[Unit]
Description=furt Multi-Tenant API Gateway
After=network.target

[Service]
Type=forking
User=furt
Group=furt
ExecStart=/usr/local/share/furt/scripts/start.sh start
PIDFile=/var/run/furt.pid
Restart=always

[Install]
WantedBy=multi-user.target

Multi-Instance Support (Optional)

Port-basierte PID-Files:

# In start.sh - Port aus Config lesen
PORT=$(grep -E "^port\s*=" /usr/local/etc/furt/furt.conf | cut -d'=' -f2 | tr -d ' ')
PID_FILE="/var/run/furt-${PORT}.pid"
echo $! > "$PID_FILE"

Service-Management:

# Port-spezifische Service-Scripts
/etc/rc.d/furt-7811
/etc/rc.d/furt-7812

Vorteile der PID-File Lösung

1. Zuverlässigkeit

Exakte Process-Identifikation
Keine False-Positive Matches
Robuste Service-Detection

2. Sicherheit

Kann nur korrekten Process killen
Keine versehentlichen Service-Kills
Audit-Trail durch PID-File

3. Platform-Kompatibilität

OpenBSD rcctl ✓
Linux systemd ✓
FreeBSD rc.d ✓
Standard Unix-Pattern ✓

4. Wartbarkeit

Ein Pattern für alle Plattformen
Einfaches Debugging (PID in Datei)
Standard Service-Management-Tools verstehen PID-Files

Testing-Plan

Phase 1: start.sh PID-File Implementation

Service-Detection einbauen (Issue #[andere Nummer])
PID-File schreiben bei Background-Start
Interactive Mode ohne PID-File
Cleanup bei Service-Exit

Phase 2: Service-Scripts anpassen

OpenBSD rc.d PID-basiert umstellen
Linux systemd Service mit PIDFile
FreeBSD rc.d analog zu OpenBSD
Alte pexp-Pattern entfernen

Phase 3: Multi-Platform Testing

OpenBSD (werner) - bereits getestet, Service läuft
Debian/Ubuntu auf tiamat
Arch Linux (karl/erna)
FreeBSD (falls relevant)

Phase 4: Edge-Cases

Service-Crash Scenarios (PID-File Cleanup)
System-Reboot (Stale PID-Files)
Permission-Problems (/var/run/ Zugriff)
Multiple Start-Versuche

Implementation-Reihenfolge

start.sh Service-Detection (Issue #[andere Nummer])
PID-File Implementation (dieses Issue)
rc.d Script Update (OpenBSD zuerst)
systemd Service Update (Linux)
Multi-Platform Testing
Documentation Update (Installation.md)

Akzeptanzkriterien

doas rcctl start furt → (ok)
doas rcctl check furt → (ok)
doas rcctl stop furt → Service gestoppt, PID-File entfernt
Service-Restart funktioniert zuverlässig
Keine False-Positive Process-Matches
Platform-übergreifend konsistent
Stale PID-File Handling

Betroffene Dateien

scripts/start.sh - PID-File schreiben
Installation.md - Service-Management-Sektion
Beispiel-rc.d-Scripts für verschiedene Plattformen
Systemd Service-Beispiele

Priorität: Medium - Service läuft, aber Management ist unzuverlässig
Aufwand: Medium - Cross-Platform Testing erforderlich
Impact: Zuverlässige Service-Verwaltung für Production-Systeme

## Problem Das aktuelle Service-Management verwendet pexp-Pattern die unzuverlässig und unsicher sind. **werner-Testing Erkenntnisse:** - furt läuft stabil und funktionsfähig - `rcctl check furt` zeigt (failed) obwohl Service läuft - pexp-Pattern `/usr/local/bin/lua src/main.lua.*` matcht nicht den tatsächlichen Process - Tatsächlicher Process: `lua src/main.lua (lua51)` ## pexp-Pattern Probleme ### 1. Platform-spezifische Unterschiede ```bash # OpenBSD ps aux: lua src/main.lua (lua51) # Linux ps aux: /usr/bin/lua5.1 src/main.lua # Arch Linux ps aux: /usr/bin/lua src/main.lua ``` **Ein Pattern funktioniert nicht überall.** ### 2. Security-Risiken ```bash # Aktuelles Pattern: pexp="lua src/main.lua.*" # Matcht JEDEN Lua-Service mit src/main.lua: _furt 12345 lua src/main.lua # furt _other 67890 lua src/main.lua # anderes Programm _app 11111 lua src/main.lua # noch ein Service # rcctl stop furt killt ALLE! ``` ### 3. Multi-Instance Probleme - Verschiedene furt-Instanzen auf verschiedenen Ports - Development vs Production parallel - Keine eindeutige Identifikation möglich ### 4. Maintenance-Overhead - Pattern muss für jeden OS angepasst werden - Debugging schwierig (welcher Process wird gematcht?) - Fragile Implementation ## Lösung: PID-File Service-Management ### Warum PID-Files besser sind **Eindeutigkeit:** Eine PID gehört exakt einem Process **Sicherheit:** Kann nur den korrekten Process killen **Platform-unabhängig:** PIDs funktionieren überall gleich **Standard-Pattern:** Etablierte Unix/Linux-Konvention **Multi-Instance-fähig:** Verschiedene PID-Files möglich ### Implementation #### 1. start.sh erweitern **Service-Detection + PID-File:** ```bash # Service vs Interactive Detection if [ ! -t 0 ] || [ ! -t 1 ]; then # Service mode - Background + PID-File "$LUA_COMMAND" src/main.lua & PID=$! echo $PID > /var/run/furt.pid echo "Furt started (PID: $PID)" else # Interactive mode - Foreground (kein PID-File) exec "$LUA_COMMAND" src/main.lua fi ``` #### 2. rc.d Script umstellen **OpenBSD rc.d ohne pexp:** ```bash #!/bin/ksh daemon="/usr/local/share/furt/scripts/start.sh" daemon_user="_furt" daemon_cwd="/usr/local/share/furt" daemon_flags="start" # PID-File basierte Funktionen rc_check() { [ -f /var/run/furt.pid ] && kill -0 $(cat /var/run/furt.pid) 2>/dev/null } rc_stop() { if [ -f /var/run/furt.pid ]; then kill $(cat /var/run/furt.pid) 2>/dev/null rm -f /var/run/furt.pid fi } . /etc/rc.d/rc.subr rc_cmd $1 ``` #### 3. Systemd Service (Linux) **Native PID-File Support:** ```ini [Unit] Description=furt Multi-Tenant API Gateway After=network.target [Service] Type=forking User=furt Group=furt ExecStart=/usr/local/share/furt/scripts/start.sh start PIDFile=/var/run/furt.pid Restart=always [Install] WantedBy=multi-user.target ``` ### Multi-Instance Support (Optional) **Port-basierte PID-Files:** ```bash # In start.sh - Port aus Config lesen PORT=$(grep -E "^port\s*=" /usr/local/etc/furt/furt.conf | cut -d'=' -f2 | tr -d ' ') PID_FILE="/var/run/furt-${PORT}.pid" echo $! > "$PID_FILE" ``` **Service-Management:** ```bash # Port-spezifische Service-Scripts /etc/rc.d/furt-7811 /etc/rc.d/furt-7812 ``` ## Vorteile der PID-File Lösung ### 1. Zuverlässigkeit - **Exakte Process-Identifikation** - **Keine False-Positive Matches** - **Robuste Service-Detection** ### 2. Sicherheit - **Kann nur korrekten Process killen** - **Keine versehentlichen Service-Kills** - **Audit-Trail durch PID-File** ### 3. Platform-Kompatibilität - **OpenBSD rcctl** ✓ - **Linux systemd** ✓ - **FreeBSD rc.d** ✓ - **Standard Unix-Pattern** ✓ ### 4. Wartbarkeit - **Ein Pattern für alle Plattformen** - **Einfaches Debugging** (PID in Datei) - **Standard Service-Management-Tools** verstehen PID-Files ## Testing-Plan ### Phase 1: start.sh PID-File Implementation - [ ] Service-Detection einbauen (Issue #[andere Nummer]) - [ ] PID-File schreiben bei Background-Start - [ ] Interactive Mode ohne PID-File - [ ] Cleanup bei Service-Exit ### Phase 2: Service-Scripts anpassen - [ ] OpenBSD rc.d PID-basiert umstellen - [ ] Linux systemd Service mit PIDFile - [ ] FreeBSD rc.d analog zu OpenBSD - [ ] Alte pexp-Pattern entfernen ### Phase 3: Multi-Platform Testing - [ ] OpenBSD (werner) - bereits getestet, Service läuft - [ ] Debian/Ubuntu auf tiamat - [ ] Arch Linux (karl/erna) - [ ] FreeBSD (falls relevant) ### Phase 4: Edge-Cases - [ ] Service-Crash Scenarios (PID-File Cleanup) - [ ] System-Reboot (Stale PID-Files) - [ ] Permission-Problems (/var/run/ Zugriff) - [ ] Multiple Start-Versuche ## Implementation-Reihenfolge 1. **start.sh Service-Detection** (Issue #[andere Nummer]) 2. **PID-File Implementation** (dieses Issue) 3. **rc.d Script Update** (OpenBSD zuerst) 4. **systemd Service Update** (Linux) 5. **Multi-Platform Testing** 6. **Documentation Update** (Installation.md) ## Akzeptanzkriterien - [ ] `doas rcctl start furt` → (ok) - [ ] `doas rcctl check furt` → (ok) - [ ] `doas rcctl stop furt` → Service gestoppt, PID-File entfernt - [ ] Service-Restart funktioniert zuverlässig - [ ] Keine False-Positive Process-Matches - [ ] Platform-übergreifend konsistent - [ ] Stale PID-File Handling ## Betroffene Dateien - `scripts/start.sh` - PID-File schreiben - `Installation.md` - Service-Management-Sektion - Beispiel-rc.d-Scripts für verschiedene Plattformen - Systemd Service-Beispiele **Priorität:** Medium - Service läuft, aber Management ist unzuverlässig **Aufwand:** Medium - Cross-Platform Testing erforderlich **Impact:** Zuverlässige Service-Verwaltung für Production-Systeme

michael added the

coordination/cross-repo

labels 2025-09-02 18:58:38 +02:00

michael added this to the v0.1.2 - Gateway Basics milestone 2025-09-02 18:58:58 +02:00

michael referenced this issue

2025-09-02 21:36:58 +02:00

Dokumentation: OpenBSD rc.d Service-File Fix und Deployment-Workflow #79

michael referenced this issue

2025-09-02 21:38:43 +02:00

Security: Eindeutigere pexp-Pattern für Service-Isolation #80

michael commented

2025-09-05 22:26:08 +02:00

Author

Owner

Scope Update: Robustes PID-File Service-Management

Erweiterte Implementation basierend auf Testing-Erfahrungen:

Original Scope (PID-File Basics)

PID-File schreiben statt pexp-Pattern
Platform-übergreifende Kompatibilität
Service-vs-Interactive-Detection

Erweiterte Robustheit (gleicher Testing-Aufwand)

Graceful Shutdown mit Timeout - verhindert hängende Processes
Process-Validation nach Start - verhindert kaputte PID-Files
SIGHUP Config-Reload - Standard Unix-Service-Pattern
PID-File Cleanup bei Service-Exit

Rationale: Zusammenhängende Service-Management-Features einmal richtig testen statt 3x separate Issues mit jeweiligem walter/werner Testing-Aufwand.

Ausgeschlossen: systemd Security-Hardening (separates Issue #110)

Status: Implementation in feature/pid-file-service-management branch bereit für Testing

## Scope Update: Robustes PID-File Service-Management **Erweiterte Implementation basierend auf Testing-Erfahrungen:** ### Original Scope (PID-File Basics) - [x] PID-File schreiben statt pexp-Pattern - [x] Platform-übergreifende Kompatibilität - [x] Service-vs-Interactive-Detection ### Erweiterte Robustheit (gleicher Testing-Aufwand) - [x] **Graceful Shutdown mit Timeout** - verhindert hängende Processes - [x] **Process-Validation nach Start** - verhindert kaputte PID-Files - [x] **SIGHUP Config-Reload** - Standard Unix-Service-Pattern - [x] **PID-File Cleanup** bei Service-Exit **Rationale:** Zusammenhängende Service-Management-Features einmal richtig testen statt 3x separate Issues mit jeweiligem walter/werner Testing-Aufwand. **Ausgeschlossen:** systemd Security-Hardening (separates Issue #110) **Status:** Implementation in `feature/pid-file-service-management` branch bereit für Testing

michael added

and removed

labels 2025-09-05 22:27:41 +02:00

michael referenced this issue

2025-09-05 22:28:31 +02:00

Update Installation.md for helper scripts system #102

michael referenced this issue

2025-09-05 22:30:10 +02:00

systemd Service Hardening: Security-Optionen für Production #110

michael referenced this issue from a commit

2025-09-05 22:33:03 +02:00

feat(service): implement PID-file based service management (DAW/furt#100)

michael referenced this issue

2025-09-07 13:42:00 +02:00

install.sh: Add --update-services parameter for service script updates #112

michael referenced this issue from a commit

2025-09-07 17:00:50 +02:00

feat(service): implement PID-file based service management

michael referenced this issue from a commit

2025-09-07 17:51:15 +02:00

feat(service): merge PID-file based service management (#100)

michael closed this issue

2025-09-07 17:51:15 +02:00

michael commented

2025-09-07 17:53:56 +02:00

Author

Owner

✅ Issue #100 Successfully Completed

Implementation completed and tested on werner (OpenBSD):

✅ Changes Made

PID-directory creation in setup-directories.sh (/var/run/furt/ with _furt:_furt)
start.sh PID-file support for service vs interactive mode detection
OpenBSD rc.d script with PID-file based rc_check() function
systemd service PIDFile parameter corrected
Cross-platform paths unified to /var/run/furt/furt.pid

✅ Testing Results

werner$ doas rcctl check furt
furt(ok)

werner$ curl http://127.0.0.1:7811/health
{"status":"healthy", ...}

✅ Git Integration

Feature-branch: feature/pid-file-service-management
Merged to main: --no-ff merge for milestone visibility
Commits: 59f372f (implementation) + bbbbeef (merkwerk auto-update)

✅ Platform Status

OpenBSD: rcctl check/start/stop/restart works reliably
Linux: systemd service with PIDFile= support ready

Result: Service detection now works reliably across platforms. The fragile pexp-pattern approach has been replaced with robust PID-file based service management.

Ready for production deployment.

## ✅ Issue #100 Successfully Completed **Implementation completed and tested on werner (OpenBSD):** ### ✅ Changes Made - **PID-directory creation** in setup-directories.sh (/var/run/furt/ with _furt:_furt) - **start.sh PID-file support** for service vs interactive mode detection - **OpenBSD rc.d script** with PID-file based rc_check() function - **systemd service** PIDFile parameter corrected - **Cross-platform paths** unified to /var/run/furt/furt.pid ### ✅ Testing Results ``` werner$ doas rcctl check furt furt(ok) werner$ curl http://127.0.0.1:7811/health {"status":"healthy", ...} ``` ### ✅ Git Integration - **Feature-branch:** feature/pid-file-service-management - **Merged to main:** --no-ff merge for milestone visibility - **Commits:** 59f372f (implementation) + bbbbeef (merkwerk auto-update) ### ✅ Platform Status - **OpenBSD:** rcctl check/start/stop/restart works reliably - **Linux:** systemd service with PIDFile= support ready **Result:** Service detection now works reliably across platforms. The fragile pexp-pattern approach has been replaced with robust PID-file based service management. **Ready for production deployment.**

michael added

and removed

labels 2025-09-07 17:54:35 +02:00

michael referenced this issue

2025-09-07 19:12:31 +02:00

systemd Service Hardening: Security-Optionen für Production #110