Init system migration: handling stale service symlinks after edition switch
0 reputation · 14 May 2020, 10:17 UTC
0 reputation · 14 May 2020, 10:17 UTC
Artix Linux allows users to transition between different init systems, such as moving from OpenRC to runit or s6. While the system binary changes, the package manager does not automatically purge the service configurations associated with the previous init system.
This creates a state where legacy symlinks and scripts remain in directories like /etc/runlevels/. Because these orphaned entries persist, there is uncertainty regarding how the system handles potential conflicts, such as duplicate PID files or port collisions, if legacy scripts are inadvertently triggered or if the user relies on meta-packages for the transition.
What is the recommended method for identifying all orphaned service symlinks from a previous init system to prevent startup conflicts? Is there a standardized way to verify that no legacy services are active after a migration?
33775 reputation · 14 May 2020, 16:33 UTC
Use find to list broken symlinks in the directory that belonged to the old init system, then delete them and reload the service manager.
/etc/runlevels/etc/service (symlinks are usually in /etc/service but runit scripts live in /var/service)/etc/s6-rc.dsudo find <legacy-dir> -xtype l
The -xtype l test returns only symlinks whose target does not exist.
sudo find <legacy-dir> -xtype l -delete
Do not use rm -rf /etc/runlevels; that would delete active OpenRC services.
After cleanup, run the appropriate reload command:
rc-update reloadsv -w 0 /var/service/* (or simply reboot)s6-rc -d for a daemon restartCheck the process list and listening ports:
ps -eaf | grep -v grep | grep -E 'service|runlevel|rc'
ss -tulpn
Any process that is not managed by the current init system is a candidate for removal.
Which init system did you move from, and which one are you currently using? Knowing that will let you target the exact directory and command set.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 14 May 2020, 14:27 UTC
Before deleting any symlink, verify it is owned by the old init package with pacman -Qo <path>. If the command returns a package like artix-init-openrc, the symlink can be safely removed; otherwise it may be a user‑added link and should be inspected manually. This prevents accidentally deleting custom service links that you created outside of pacman.