Bug#824804: update-rc.d: may invoke insserv without -f flag when initscripts is installed but not configured
Felipe Sateler
fsateler at debian.org
Wed Jun 29 14:36:52 BST 2016
On 28 June 2016 at 06:13, Martin Pitt <mpitt at debian.org> wrote:
> Control: tag -1 pending
>
> Hello Felipe,
>
> CC'ing Andreas for the util-linux part.
>
> Felipe Sateler [2016-05-19 17:57 -0400]:
>> update-rc.d currently has support for invoking insserv with the -f flag,
>> to allow initscripts-less installations. This should allow packages to drop
>> dependencies on the initscripts package. However, this does not work if the
>> dependency is dropped, because now apt/dpkg can choose to configure the
>> package before it configures initscripts. This leads to the situation that
>> /etc/init.d/mountkernfs.sh exists (and thus invoke-rc.d does not pass -f flag),
>> but the links in /etc/rc?.d/S??mountkernfs.sh are not created yet, and then
>> insserv fails.
>
> I have some trouble reproducing this. In a schroot without initscipts,
> when I do
>
> dpkg --unpack initscripts_2.88dsf-59.7_amd64.deb
>
> then there's only /etc/init.d/mountkernfs.sh.dpkg-new, as the
> conffiles are only moved into place at configure time, not at unpack
> time yet. And on upgrades the script and the previous rc?.d links
> should already be in place.
>
> So could it be that this is limited to debootstrap as that might just
> directly unpack conffiles instead of installing them as *.dpkg-new on
> unpack? This would make sense for debootstrap as that isn't concerned
> about upgrades.
>
> With this synthetic test I can reproduce it:
>
> apt-get download initscripts
> dpkg --unpack initscripts_*.deb
> mv /etc/init.d/mountkernfs.sh{.dpkg-new,}
> update-rc.d hwclock.sh defaults
>
>> 2. Extend the check to the links (ie, check if
>> `glob /etc/rc?.d/S??mountkernfs.sh` is not empty.
>
> I agree that this seems to be the best solution for now. Checkin for
> /etc/init.d/mountkernfs.sh was supposed to be a test for "initscripts
> is installed", but as you found it is only a sufficient test for
> "initscripts is unpacked".
>
> So I think this is mostly just limited to debootstrap and thus
> util-linux. But I'd indeed prefer if we do this in update-rc.d and
> drop the workaround from util-linux again.
>
>> 3. Consult the dpkg database via dpkg-query to determine if initscripts has been
>> configured
>
> Sounds fine as well, but more expensive than globbing, and actually
> not quite trivial either. "dpkg-query --showformat='${Status}' --show"
> needs parsing and has a trap as its package arguments are patterns,
> not fixed names. And "dpkg-query --status" would also need a
> non-trivial (but still simple, however) grep.
>
> So I committed this now:
>
> http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=14008bd4a
>
> I tested this with three scenarios (no initscripts, unpacked
> initscripts, configured initscripts) in a schroot and it now works
> fine. Does that sound ok to you?
I was very confused by this mail. We had already committed this same
fix in 79a4036f (in 1.34), so I wondered why was this still a problem.
Turns out the patch I applied on c167d9498a inadvertently reverted the
change :/
So, +1 from me.
--
Saludos,
Felipe Sateler
More information about the Pkg-systemd-maintainers
mailing list