On 1/11/19 8:36 AM, Dmitry Bogatov wrote: > > [ I believe this bug should be reassigned to bin:insserv, if current > maintainer of bin:init-system-helpers agree. ] > > [2012-02-15 11:33] Peter Eisentraut <pet...@debian.org> >> part text/plain 238 >> Package: sysv-rc >> Version: 2.88dsf-22 >> Severity: wishlist >> >> Please add an option like insserv -p or chkconfig --root to specify an >> alternative root for the init scripts. This would be useful for >> testing and for fixing other file systems. > > According to insserv(8), it must be possible (insserv=1.18.0): > > [[/]path/to/init.d/] > Relative or absolute path to the init scripts base directory. > This defaults to /etc/init.d/ in compliance with the LSB speci‐ > fication. In this case insserv does not add or remove a script > to the runlevels declared in the script headers, but may > re-order the runlevels if the order of the currently enabled > scripts has changed (see option -d). Note that if a relative > path is used insserv has to be called from the root directory. > > but I failed to make use of it: > > $ mkdir /tmp/temp-1 > $ cp -r /etc/init.d . > $ /sbin/insserv init.d > $ ls > init.d rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d rcS.d > $ find -empty > ./rcS.d > ./rc6.d > ./rc5.d > ./rc4.d > ./rc3.d > ./rc2.d > ./rc1.d > ./rc0.d > > Jesse, am I holding it wrong? >
The quoted part of the insserv manual page says when a relative path is used insserv must be called from the root directory. In this case I wonder if the man page is being ambiguous about whether it means root as in "/" or root as in the top-level directory the user is working in. I'm starting to suspect the former. What happens if the steps are changed to be as follows: mkdir /tmp/temp-1 cd /tmp/temp-1 cp -r /etc/init.d . cd / /sbin/insserv tmp/temp-1/init.d If this way works then it's a limitation of insserv and should be better documented on my end. If it doesn't work, then we have a bug I need to fix.
