[Nut-upsuser] SSL only working in DEBUG mode
Charles Lepple
clepple at gmail.com
Sun Apr 12 19:13:18 UTC 2015
On Sun, Mar 29, 2015 at 1:50 PM, Melkor Lord <melkor.lord at gmail.com> wrote:
> On Thu, Mar 26, 2015 at 9:16 AM, Emilien Kia <kiae.dev at gmail.com> wrote:
>>
>>
>>
>> After looking a bit deeply, we have another little problem. When we intend
>> to start upsd with the init script (at least under debian-based distrib -
>> tested on Linux Mint 17.1) when we have the NSS problem, the init script
>> exit with the "[OK]" state even if the "real" deamon process does not run
>> correctly.
>>
>> Perhaps we could add some tests to validate if the deamonization is OK.
>> But it is a little bit out of my competencies (I am not a bash and
>> linux-init-process expert).
The Ubuntu/Mint script is explicitly catching any non-zero exit codes
(with the '|| log_progress_msg "(upsd failed)"' portion). I wonder if
this was intentional to keep going after upgrades, the way that the
Debian+systemd scripts do?
> I'm running Ubuntu Server 14.04 in all the servers I maintain and also use
> NUT. The process is started with the following command in
> /etc/init.d/nut-server:
>
> start-stop-daemon -S -p $upsd_pid -x $upsd \
> -- $UPSD_OPTIONS >/dev/null 2>&1 &&
> log_progress_msg "upsd" || log_progress_msg "(upsd failed)"
>
> and obviously, a backslash is missing on the second line! (line 83 on the
> real script) So even if it fails, the next command (log_process_msg) will
> always start as if the previous command returned 0 (OK). This script always
> write "upsd" after starting instead of the right text, depending on the
> correct execution of $upsd!
Close, but not quite. If I tweak $upsd to point to the wrong filename
(after the -x check at the beginning), it will call the second
log_progress_msg() on my system (Mint 17). See below for the reason.
> In normal conditions, this construction shouldn't work. Try "ping localhost
> &&" for example and any shell would wait for more data before executing the
> line.
>
> But these lines are in a function which is called inside a switch/case
> construct and by some nesting effect and redirection to /dev/null, it works
> with the missing backslash and nothing is printed out!
The backslash is needed on the start-stop-daemon line because it is
syntactically complete as-is. The line ending in "&&" is not complete,
so the shell continues to read to the next line.
The fact that it prints nothing is due to Ubuntu redefining
log_progress_msg() in /lib/lsb/init-functions.d/50-ubuntu-logging
(which masks the definition in /lib/lsb/init-functions).
More information about the Nut-upsuser
mailing list