Bug 3948 - /usr/sbin/invoke-rc.d error breaks daemon inst/remv/upgr
: /usr/sbin/invoke-rc.d error breaks daemon inst/remv/upgr
Status: RESOLVED WONTFIX
Product: Location
General
: 4.1.3 (5.2008.43-7)
: All Maemo
: Low normal with 2 votes (vote)
: ---
Assigned To: unassigned
: location-framework-bugs
:
:
: int-96574/int-96575 int108362/int-113308
:
  Show dependency tree
 
Reported: 2008-12-21 00:10 UTC by tz
Modified: 2009-05-31 13:10 UTC (History)
4 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description tz (reporter) 2008-12-21 00:10:02 UTC
SOFTWARE VERSION:
(Control Panel > General > About product)
5.2008.43-7

STEPS TO REPRODUCE THE PROBLEM:
Unknown.  Other than updating an existing program that has something in
/etc/rc2.d symlinked to /etc/init.d

EXPECTED OUTCOME:
upgraded.

ACTUAL OUTCOME:
Fails.
Log includes:

Upgrading agps-ui 0.12-1beta to 0.12-1beta
Setting up supl-daemon (0.28) ...
invoke-rc.d: not a symlink: "/etc/rc2.d/S54supllistenerd"
invoke-rc.d: dangling symlink: "/etc/rc2.d/S54supllistenerd"
dpkg: error processing supl-daemon (--configure):
 subprocess post-installation script returned error exit status 102
dpkg: dependecy problems prevent configuration fo agps-ui
(further messages saying agps-ui depends on supl-daemon which isn't
configured).

S54supllistenerd was a valid symlink and pointed to ../etc/init.d/supllistenerd
which existed and was apparently correct.

Around line 305 in the invoke-rc.d script are the tests (and exit code 102).  I
have no idea why they failed.

This has happened to me at least twice before.  The way to get past these is to
delete both the symlink and the actual program it points to, but it won't
restore these two files (perhaps they were removed since the un/reinstall
didn't put them back).

REPRODUCIBILITY:
(always/sometimes/once)
sometimes

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5)
Gecko/2008120122 Firefox/3.0.5
Comment 1 tz (reporter) 2008-12-21 05:48:32 UTC
The root cause is (busybox) xargs NOT removing quotes.

echo \"x\" | xargs

will return x under gnu xargs, but "x" under busybox xargs.

This is within /sbin/invoke-rc.d

The problem occurs at the lines: if test ! -L "$1" ; then... and the -f.

There is a valid symlink:

Nokia-N810-WiMAX-43-7:/var/lib# test -L /etc/rc2.d/S54supllistenerd 
Nokia-N810-WiMAX-43-7:/var/lib# echo $?
0
Nokia-N810-WiMAX-43-7:/var/lib# test ! -L /etc/rc2.d/S54supllistenerd 
Nokia-N810-WiMAX-43-7:/var/lib# echo $?
1

strace shows for some reason the quotes are included in the filename.

lstat64("\"/etc/rc2.d/S54supllistenerd\"", 0xbeca1950) = -1 ENOENT (No such
file or directory)

stat64("\"/etc/rc2.d/S54supllistenerd\"", 0xbeca1950) = -1 ENOENT (No such file
or directory)

note the \" in the filename.

Just below verifyclink, sh -x reveals:
+ ls -d -Q /etc/rc2.d/S54supllistenerd
+ xargs
+ SLINK="/etc/rc2.d/S54supllistenerd"

The -Q encloses the name in quotes, and xargs

The whole line is:

SLINK=`ls -d -Q ${RCDPREFIX}${RL}.d/S[0-9][0-9]${INITSCRIPTID} 2>/dev/null |
xargs`

busybox strikes again.

Under ubuntu, ls -Q XXX  results in "XXX" which xargs reduces to XXX

On the tablet with busybox xargs, "XXX" comes out as XXX.

verifyrclink () {
  #
  # verifies if parameters are non-dangling symlinks
  # all parameters are verified
  #
  doexit=
  while test $# -gt 0 ; do
    if test ! -L "$1" ; then
        printerror not a symlink: $1
        doexit=102
    fi
    if test ! -f "$1" ; then
        printerror dangling symlink: $1
        doexit=102
    fi
    shift
  done
  if test x${doexit} != x && test x${RETRY} = x; then
     exit ${doexit}
  fi
  return 0
}
Comment 2 tz (reporter) 2008-12-21 06:39:46 UTC
Changed title to focus on the precise problem.

It affects upgrading supld (and hence agps-ui) which was the original report.

/usr/sbin/invoke-rc.d uses "ls -Q" (quote the filenames) with xargs, but the
busybox xargs does NOT remove the quotes, so the script breaks.

This script is used in many of the pre/post inst/rm scripts for the /etc/init.d
startup daemon deb packages and tends to result in the package stuck in an
unconfigured state (which isn't fixed by a reboot since although the new
scripts are in /etc/init.d, apt-* and dpkg will not be satisfied until this
script succeeds and it never will).
Comment 3 Eero Tamminen nokia 2008-12-22 11:07:17 UTC
> /usr/sbin/invoke-rc.d uses "ls -Q" (quote the filenames) with xargs, but
> the busybox xargs does NOT remove the quotes, so the script breaks.

I added bug 3951 for the Busybox xargs behavior (same also in v1.10.2).

But I think this Busybox issue's more likely cause for this:
  ~# ls -d -Q  
  ls: invalid option -- Q
?
Comment 4 tz (reporter) 2008-12-22 16:46:07 UTC
Ah, I had a real version of ls in /usr/local/bin which supported -Q properly.

(/etc/invoke-rc.d ends up bypassing the test since the line gives a NULL for
the symlink so it processes the direct link with -Q).

I wonder if this is the cause other places too.
Comment 5 Andre Klapper maemo.org 2009-01-15 13:40:14 UTC
So if I get this right this depends on fixing ls -Q (bug 3957) and
quote handling in xargs (bug 3951).
Adding dependencies.
Comment 6 tz (reporter) 2009-01-15 15:31:52 UTC
Yes, the offending lines in the invoke script has both ls -Q (which fails), but
if that is fixed, the xargs will make things worse.

The script is succeeding because it tries several things in order, and the
second one just happens to work.

It might be possible to remove this script completely (the debian
pre/post/inst/rm scripts will try directly if the script is not around).
Comment 7 Andre Klapper maemo.org 2009-05-31 13:10:27 UTC
(In reply to comment #2)
> It affects upgrading supld (and hence agps-ui)

WONTFIX as Diablo will only receive critical fixes && no more development is
done for Diablo's location framework (see bug 2878 comment 139).
This bug will also not apply for Fremantle as there's too much stuff changed in
the Location framework (INVALID for Fremantle).
Sorry.