I've been bitten this morning by bug 6296119 "lsvcrun doesn't seem to
honor #! interpreter specifications" which was closed as "Not a Defect"
some time ago. I'm about to beg to differ, although obviously I haven't
seen why that was considered "not a defect".
It looks like lsvcrun (and supporting infrastructure such as rc[0-3S])
has behaviour which will cause it to execute all init scripts that don't
end in .sh directly with /bin/sh.
As an example, usr/src/cmd/initpkg/rc3.sh contains the following lines:
73 for f in /etc/rc3.d/K*; do
74 if [ -s $f ]; then
75 case $f in
76 *.sh) /lib/svc/bin/lsvcrun -s $f stop ;;
77 *) /lib/svc/bin/lsvcrun $f stop ;;
78 esac
79 fi
80 done
usr/src/cmd/svc/lsvcrun/lsvcrun.c handles the argument -s as follows:
829 while ((o = getopt(argc, argv, "s")) != -1) {
830 switch (o) {
831 case 's':
832 source = 1;
833 break;
and later in the file, the boolean_t source is used to choose between
the following behaviour (after a fork()):
916 if (!source) {
917 arg1 = "/bin/sh";
918 arg2 = script;
919 arg3 = action;
920 } else {
921 arg1 = "/bin/sh";
922 arg2 = "-c";
923 arg3 = script;
924 }
i.e., /etc/rc3.d/K99blah is executed as "/bin/sh /etc/rc3.d/K99blah
start", and /etc/rc3.d/K99foo.sh is executed as
"/bin/sh -c /etc/rc3.d/K99foo.sh".
Firstly, this is clearly the wrong way around; if K99blah were, say, a
binary or /bin/bash script then forcing it to be interpreted with /bin/sh
is not a good thing.
Additionally, in the second case the action is being lost.
I'd like to see bug 6296119 reopened, or an explanation of why the above
isn't considered a defect, and then I'd like to request that someone
sponsor me via the request-sponsor program to fix it.
Cheers,
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20080616/40606c20/attachment.bin>
