From: Raphael Cohn <raphael.cohn@stormmq.com>
To: musl@lists.openwall.com
Subject: Re: setenv if value=NULL, what say standard? Bug?
Date: Thu, 23 Apr 2015 10:52:10 +0100 [thread overview]
Message-ID: <CACCP0Gqd60JLtbD=iy1a2Vbcry87NgyzdEJ+E=Are3nzh4Vjbw@mail.gmail.com> (raw)
In-Reply-To: <5538BA11.90402@skarnet.org>
[-- Attachment #1: Type: text/plain, Size: 4441 bytes --]
On 23 April 2015 at 10:23, Laurent Bercot <ska-dietlibc@skarnet.org> wrote:
> On 23/04/2015 06:24, Jean-Marc Pigeon wrote:
>
>> Think about this, you write an application working perfectly right,
>> but 1 in 1000000 you reach something not trapped by low level and
>> once in while the application (in production for month) just stop
>> to work because "unexpected" within musl...
>>
>
> And why do you think the problem exists in the first place ?
> Because other libcs were defensive and failed to fail early, so the
> bug was never discovered until now. Your application is not working
> perfectly right - it is buggy, and it *should* fail. musl is giving
> developers a gift that other libcs do not: it helps them debug.
>
>
> (so someone will propose to set a cron to automatically restart this
>> unreliable daemon, hmmm...)
>>
>
> You want to be defensive, well, yeah, this is the place to be
> defensive. Until the bug is found and fixed, at least the daemon is
> kind of providing service.
>
> Raphael says this behaviour is wrong for the same reason that
> silently failing is wrong, but I disagree. First, restarting crashing
> daemons is not silent at all, a crash is always a loud warning and
> can hardly be ignored; and second, restarting a process is not
> continuing it. A process can always be restarted from a clean state
> and work in a predictable way until it trips the bug again, whereas
> silently ignoring UB makes the process unpredictable for the rest of
> its lifetime.
Yes and no. Crashes are loud and noisy, and should immediately trigger
alerts, but without intimate knowledge of the application and the cause of
the fault, auto-restarting is risky. In my operational experience, it's
usually been a hack employed by incompetent sysadmins (no names, no pack
drill, but one large government dept comes to mind). If you have knowledge
of your daemon processes, then you could if:-
- you know they are idempotent or do not have persistent state (eg DNS
caches)
- they're essential system services (definitions might vary, but I'd have
ssh for geographically remote boxes here)
That said, stuff that has complex state really shouldn't be restarted
without *investigation* - message brokers, relational database titans,
cluster HA set ups, etc. The worst outage of my career was a terracotta
cluster that had suffered from a split brain. Restarting it naively caused
it to _delete_ the only remaining good state. Is this your 'clean state'
caveat above?
>
>
> Far better to return "trouble" status, then it is to the application
>> to decide what must be done in context, as ignore, override, bypass,
>> crash, etc.
>>
>
> What "trouble" status do you return when a function dereferences a
> NULL pointer ? This is exactly what's happening here. Passing NULL
> to setenv is as incorrect as dereferencing NULL, and should result
> in the same behaviour.
>
>
> A sensible policy in case of UB would be for such low level code to
>> swallow the problem, (protect the hardware and keep the program
>> running as much as possible).
>>
>
> The language you want is Javascript, not C.
>
>
> As reported, the crashing application is hwclock, (util-linux-2.26),
>> this a kind of code in the field for a very very long time, so the
>> library (glibc and old libc) used for linux over the years defined an
>> expected behavior to this "UB".
>>
>
> And this is why musl is so much better. If glibc and uclibc devs
> hadn't been so complacent, the bug wouldn't have lived for so long.
>
>
> Crashing is not an option for code pertaining to musl/libc layer.
>>
>
> It definitely is. You don't want your program to crash ? Don't
> invoke UB.
> If you want to be "safe", you can ignore SIGSEGV at the start of
> all your applications - it will be the exact same thing as what you
> are asking. Your daemons will live longer, I guarantee it.
>
>
> (:-} why bother to return an error, just crash for all
>> problems in open, close, write, etc. just bringing the crashing
>> concept to the extreme :-}).
>>
>
> Straw man. You know as well as we do the difference between a
> programming error and a run-time error.
>
>
> My experience (for a long time now) about writing complex daemon
>> running for months/year, it is not that straightforward (may
>> be for a simple application it is)
>>
>
> And mine is that it is. We're evens, now please let's stop bringing
> up anecdotal evidence.
>
> --
> Laurent
>
>
[-- Attachment #2: Type: text/html, Size: 6449 bytes --]
next prev parent reply other threads:[~2015-04-23 9:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-23 0:08 Jean-Marc Pigeon
2015-04-23 0:35 ` Laurent Bercot
2015-04-23 1:26 ` Jean-Marc Pigeon
2015-04-23 2:15 ` Rich Felker
2015-04-23 4:24 ` Jean-Marc Pigeon
2015-04-23 5:08 ` Raphael Cohn
2015-04-23 12:29 ` Jean-Marc Pigeon
2015-04-23 9:23 ` Laurent Bercot
2015-04-23 9:52 ` Raphael Cohn [this message]
2015-04-23 10:47 ` Laurent Bercot
2015-04-23 10:10 ` Rich Felker
2015-04-23 12:58 ` Jean-Marc Pigeon
2015-04-23 13:22 ` Szabolcs Nagy
2015-04-23 13:58 ` Jean-Marc Pigeon
2015-04-23 14:26 ` Szabolcs Nagy
2015-04-23 8:05 ` Jens Gustedt
2015-04-23 9:55 ` Rich Felker
2015-04-24 4:11 ` Isaac Dunham
2015-04-23 5:52 ` Isaac Dunham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACCP0Gqd60JLtbD=iy1a2Vbcry87NgyzdEJ+E=Are3nzh4Vjbw@mail.gmail.com' \
--to=raphael.cohn@stormmq.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).