Okay, I think I'm convinced that the sleepd problem can be solved with
an 'eval' in the sleepd script, not the init-functions start_daemon
function. This fixes the problem for the application that needs it,
without breaking other applications.
A better solution would perhaps have a separate variable SLEEP_CMD and
would have the sleepd script wrap that as "'$SLEEP_CMD'" as one of the
arguments to start_daemon. id est:
if [ ! -z "$SLEEP_CMD" ]; then
start_daemon -p /var/run/$NAME.pid $DAEMON
$PARAMS --sleep-command "'$SLEEP_CMD'"
else
start_daemon -p /var/run/$NAME.pid $DAEMON $PARAMS
fi
This seems to work - any obvious problems? If not, I will propose to the
maintainer of sleepd.
Max Kellermann wrote, On 01/08/2007 08:17 AM:
> On 2007/01/08 15:01, Luigi Bai <[EMAIL PROTECTED]> wrote:
>> The problem arose in the use of the start_daemon function in
>> /etc/init.d/sleepd (from the sleepd package). The sleepd daemon has a -F
>> parameter which can take spaces. This is not unlike other applications
>> (such as bash!) which can take parameters with spaces, like -c.
>>
>> Assuming the configuration infrastructure that requires parameters to
>> sleepd to reside in /etc/default/sleepd, I see a problem. This PARAMS
>> environment variable must somehow encode a command line parameter which
>> can have spaces. Absent re-writing the sleepd to read its configuration
>> from a file, how would you encode the PARAMS environment variable to
>> work in this case? As you state, it's quite clear that quotes in the
>> variable value are only printable characters - they're not performing
>> the function you expect them to if they were actually on the command
>> line. Eval, however, restores that semantic to the quotes. I am not a
>> good enough shell programmer to know how to do this without the 'eval';
>> I have tried many various combinations of embedded quotes and
>> backslashes.
>
> "restoring quote semantics" is just a side effect of using eval, and
> it is a (mis-)feature which is not documented in the LSB spec. You
> could make sleepd's init script call eval to set variables somehow
> when you are sure there are no unwanted side effects, but changing
> lsb-base and bringing the horror of eval to _all_ of Debian is a bad
> thing.
>
>> In particular, what I need is for the start_daemon function to finally
>> execute the following:
>>
>> /sbin/start-stop-daemon --start --nicelevel $nice --quiet --startas $exe
>> c --pidfile /dev/null --oknodo -- /usr/sbin/sleepd --unused 0
>> --ac-unused 0 --battery 10 --sleep-command '/usr/sbin/hibernate -F
>> /etc/hibernate/suspend.conf'
>>
>> Note that the $PARAMS value is sent to the start_daemon function as part
>> of $@, and is put in the command line of start-stop-daemon after the --.
>>
>> For what value of $PARAMS can I make this work to create the output above:
>>
>> start_daemon -p /tmp/sleepd.pid /usr/sbin/sleepd $PARAMS
>>
>> With the "eval" in start_daemon, I can make it work, and I haven't seen
>> any other start scripts break. While you do document strange possible
>> behaviour for the function, where does that breakage happen in practice?
>> id est, is it a "real" regression or a "potential" one? And if it is a
>> regression, then how should the sleepd script be written to work
>> correctly with the LSB functions?
>
> It happened in a package which isn't part of Debian, but I'm sure you
> will find official packages breaking under some configured conditions
> when you look for it. If the default configuration works, that
> doesn't mean it isn't broken - just insert a dollar or a space in some
> option in /etc/default/foo, and see it break.
>
> For this bug to be valid it doesn't matter whether there is really an
> official package which breaks. It violates the LSB spec, that should
> suffice.
>
> There aren't many packages using start_daemon yet, but with a broken
> implementation, it will be hard to convince maintainers to use it.
>
> Max
>
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
