[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: crond and syslog
From:       "Laurent Bercot" <ska-dietlibc () skarnet ! org>
Date:       2017-01-14 9:55:52
Message-ID: em8ed84342-a87b-4384-a8d4-075f7727b3ec () elzian
[Download RAW message or body]

>not sure what the DGRAM socket corresponds to…  On Linux /dev/log is 
>normally implemented as a SOCK_STREAM socket, so I suspect it's not 
>that.

  It is likely that. There is no standard at all for the nature of 
/dev/log,
it all depends on your syslogd. Old versions of syslogd created /dev/log
as SOCK_STREAM; loggers such as rsyslogd now create it as SOCK_DGRAM by
default. socklog uses a SOCK_DGRAM, I believe; s6's implementation of
syslogd uses a SOCK_STREAM.

  Client-side, glibc supports syslog() writing to a SOCK_STREAM as well 
as
a SOCK_DGRAM. uClibc is the same IIRC. musl only supports writing to a
SOCK_DGRAM for now (unfortunately - but this will change some day if I
take the time to make a good case for SOCK_STREAM support).


>  Why would LOG_CONS be selected unconditionally?  Shouldn't that only 
>be selected if (opts & OPT_f) ?

  No, this is tradtional historic behaviour. Most programs that use
syslog() default to sending their logs to /dev/console when they cannot
reach syslogd - no matter whether they're running in the foreground or
not. "Running in the foreground" is the correct way to start services
anyway, when using a supervision system such as runit, s6, or even 
systemd
- so the presence or absence of the "-f" option should have no impact
on the way logs are managed.

  What is happening here is that your syslog client (crond) does not
manage to talk to your syslogd, and so syslog() falls back on sending 
its
data to the console. The fallback is normal; the problem happens 
earlier.

  You could strace crond in order to see where and why syslog() is 
failing
to reach syslogd, and proceed from there. If you're using musl, it's
possible that your syslogd is set up to create /dev/log as SOCK_STREAM,
and musl opens it as SOCK_DGRAM, which works because Linux is permissive
on that, but fails later on when syslog() tries to write. In that case
you should find the option in syslog-ng to make syslogd listen to a
SOCK_DGRAM, or join me in lobbying the musl author for SOCK_STREAM 
support
in syslog(). :)

  Also, unrelated: I'm not sure how OpenWRT is supposed to be built, but
generally speaking it's unusual to have C programs depend on 
libgcc_s.so;
libgcc is normally linked statically, and only C++ programs require the
dynamic version. Unless it's a deliberate design choice in OpenWRT, you
may want to investigate how your toolchain is made.

--
  Laurent

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]