olemd/skyview

Fork 0

Debian package upgrade fails to restart systemd service #21

New issue

Closed

opened 2025-08-24 23:22:00 +02:00 by olemd · 1 comment

olemd commented

2025-08-24 23:22:00 +02:00

Owner

Problem

When upgrading the SkyView Debian package, the systemd service fails to restart properly even when it was previously enabled and running. This leaves the service in a stopped state after upgrade, requiring manual intervention to restart it.

Root Cause Analysis

After investigating the package maintenance scripts, I identified the issue in the interaction between prerm and postinst scripts during upgrade:

Current Problematic Flow:

prerm script runs with parameter upgrade
- Stops the running service ✅ (correct)
- Disables the service ❌ (problematic for upgrades)
Package files are replaced
postinst script runs with parameter configure
- Checks systemctl is-enabled skyview ❌ (returns false because prerm disabled it)
- Skips restart because service appears "not enabled"
- Service remains stopped

Code Analysis

prerm script (lines 11-13):

if systemctl is-enabled --quiet skyview.service; then
    systemctl disable skyview.service    # ❌ This breaks upgrade flow
fi

postinst script (lines 32-35):

if systemctl is-enabled skyview >/dev/null 2>&1; then
    systemctl restart skyview >/dev/null 2>&1 || true   # Never executes
fi

Expected Behavior

During package upgrade:

✅ Stop running service
❌ Don't disable the service (preserve enabled state)
✅ Replace package files
✅ Restart service if it was previously enabled
✅ Service resumes operation automatically

Impact

Service downtime: Requires manual systemctl start skyview after upgrade
Production disruption: Automated upgrades leave service stopped
User confusion: Service appears broken after successful package upgrade

Proposed Solution

Option 1: Fix prerm script (Recommended)

Don't disable service during upgrade - only disable during removal:

case "$1" in
    remove|deconfigure)  # Remove 'upgrade' from this case
        if systemctl is-active --quiet skyview.service; then
            systemctl stop skyview.service
        fi
        
        if systemctl is-enabled --quiet skyview.service; then
            systemctl disable skyview.service
        fi
        ;;
    upgrade)
        # Only stop service during upgrade, don't disable
        if systemctl is-active --quiet skyview.service; then
            systemctl stop skyview.service
        fi
        ;;
esac

Option 2: Improve postinst script

Save enabled state before prerm runs and restore it:

# In prerm: save state to temp file
# In postinst: check saved state instead of current enabled status

Reproduction Steps

Install SkyView package: sudo dpkg -i skyview_0.0.3_amd64.deb
Enable service: sudo systemctl enable skyview
Start service: sudo systemctl start skyview
Verify running: sudo systemctl status skyview
Upgrade package: sudo dpkg -i skyview_0.0.4_amd64.deb
Check status: sudo systemctl status skyview
- Expected: Service running
- Actual: Service stopped and needs manual start

Environment

OS: Debian/Ubuntu systems with systemd
Package: skyview_0.0.4_amd64.deb and earlier versions
Component: Debian package maintenance scripts (prerm/postinst)
Service manager: systemd

Priority

High - This affects production deployments and automated upgrade processes.

## Problem When upgrading the SkyView Debian package, the systemd service fails to restart properly even when it was previously enabled and running. This leaves the service in a stopped state after upgrade, requiring manual intervention to restart it. ## Root Cause Analysis After investigating the package maintenance scripts, I identified the issue in the interaction between `prerm` and `postinst` scripts during upgrade: ### Current Problematic Flow: 1. **prerm script runs** with parameter `upgrade` - Stops the running service ✅ (correct) - **Disables the service** ❌ (problematic for upgrades) 2. **Package files are replaced** 3. **postinst script runs** with parameter `configure` - Checks `systemctl is-enabled skyview` ❌ (returns false because prerm disabled it) - Skips restart because service appears "not enabled" - Service remains stopped ### Code Analysis **prerm script (lines 11-13):** ```bash if systemctl is-enabled --quiet skyview.service; then systemctl disable skyview.service # ❌ This breaks upgrade flow fi ``` **postinst script (lines 32-35):** ```bash if systemctl is-enabled skyview >/dev/null 2>&1; then systemctl restart skyview >/dev/null 2>&1 || true # Never executes fi ``` ## Expected Behavior During package upgrade: 1. ✅ Stop running service 2. ❌ **Don't disable** the service (preserve enabled state) 3. ✅ Replace package files 4. ✅ Restart service if it was previously enabled 5. ✅ Service resumes operation automatically ## Impact - **Service downtime**: Requires manual `systemctl start skyview` after upgrade - **Production disruption**: Automated upgrades leave service stopped - **User confusion**: Service appears broken after successful package upgrade ## Proposed Solution ### Option 1: Fix prerm script (Recommended) Don't disable service during upgrade - only disable during removal: ```bash case "$1" in remove|deconfigure) # Remove 'upgrade' from this case if systemctl is-active --quiet skyview.service; then systemctl stop skyview.service fi if systemctl is-enabled --quiet skyview.service; then systemctl disable skyview.service fi ;; upgrade) # Only stop service during upgrade, don't disable if systemctl is-active --quiet skyview.service; then systemctl stop skyview.service fi ;; esac ``` ### Option 2: Improve postinst script Save enabled state before prerm runs and restore it: ```bash # In prerm: save state to temp file # In postinst: check saved state instead of current enabled status ``` ## Reproduction Steps 1. Install SkyView package: `sudo dpkg -i skyview_0.0.3_amd64.deb` 2. Enable service: `sudo systemctl enable skyview` 3. Start service: `sudo systemctl start skyview` 4. Verify running: `sudo systemctl status skyview` 5. Upgrade package: `sudo dpkg -i skyview_0.0.4_amd64.deb` 6. Check status: `sudo systemctl status skyview` - **Expected**: Service running - **Actual**: Service stopped and needs manual start ## Environment - **OS**: Debian/Ubuntu systems with systemd - **Package**: skyview_0.0.4_amd64.deb and earlier versions - **Component**: Debian package maintenance scripts (prerm/postinst) - **Service manager**: systemd ## Priority **High** - This affects production deployments and automated upgrade processes.

olemd referenced this issue from a commit

2025-08-31 11:26:34 +02:00

Fix issue #21 and add aircraft position tracking indicators

olemd referenced this issue

2025-08-31 11:26:46 +02:00

Fix issue #21 and add aircraft position tracking indicators #29

olemd referenced this issue from a commit

2025-08-31 11:41:50 +02:00

Merge pull request 'Fix issue #21 and add aircraft position tracking indicators' (#29) from feature/position-tracking-fixes into main

olemd closed this issue

2025-09-01 19:46:38 +02:00

olemd commented

2025-09-01 19:46:46 +02:00

Author

Owner

Issue Status: Already resolved in current codebase.

Verification: Examined the Debian package scripts and found they were already fixed:

prerm script (debian/DEBIAN/prerm):

Lines 15-21 properly handle upgrade case
Only stops service during upgrade, does NOT disable it
Preserves enabled state for postinst to detect

postinst script (debian/DEBIAN/postinst):

Lines 35-38 check if service is enabled
Automatically restarts service if it was previously enabled
Handles both main service and database timer correctly

Root Cause: The issue was likely fixed in a previous commit that updated the package maintenance scripts to follow Debian policy for service handling during upgrades.

Current Behavior: Service upgrades now preserve enabled state and automatically restart, eliminating the manual intervention requirement described in the original issue.

**Issue Status**: Already resolved in current codebase. **Verification**: Examined the Debian package scripts and found they were already fixed: **prerm script** (`debian/DEBIAN/prerm`): - Lines 15-21 properly handle `upgrade` case - Only stops service during upgrade, **does NOT disable it** - Preserves enabled state for postinst to detect **postinst script** (`debian/DEBIAN/postinst`): - Lines 35-38 check if service is enabled - Automatically restarts service if it was previously enabled - Handles both main service and database timer correctly **Root Cause**: The issue was likely fixed in a previous commit that updated the package maintenance scripts to follow Debian policy for service handling during upgrades. **Current Behavior**: Service upgrades now preserve enabled state and automatically restart, eliminating the manual intervention requirement described in the original issue.