Rainer Gerhards [Fri, 6 Mar 2015 11:12:15 +0000 (12:12 +0100)]
logger: bugfix: tcp syslog framing is broken, -T unusable
Logger can send via plain tcp syslog if -n -T options are given.
However, the framing is broken so that a syslog receiver can not
know where the first message ends and the next one starts. It
actually looks like no framing at all is used. Plain TCP syslog
framing is described in RFC6587.
This patch adds RFC6587 octet-stuffed framing to TCP syslog. For
local logging, this is always fine, for remote logging this is
NOT recommended by the IETF (the RFC is historic). However, a
full blown RFC5425 TLS sender seems to be out of scope for a tool
like logger IMO.
This patch also refactors the way output is written, seperating
the message format generators from the output writer.
Rainer Gerhards [Fri, 6 Mar 2015 10:51:31 +0000 (11:51 +0100)]
logger: refactor the way output is written
Previously, output was written in exactly the same way in three
different places. This is now combined into a single function. This
hopefully makes it easier to adapt to changing output needs.
Rainer Gerhards [Thu, 5 Mar 2015 14:20:50 +0000 (15:20 +0100)]
logger: fix invalid timestamp regression in local format
Since 1d57503378bdcd838365d625f6d2d0a09da9c29d logger no longer uses
the syslog(3) call. The way the local timestamp is generated did not
match the syslog(3) format. Most importantly, the month name is
formatted based on the user's local. For example:
$ ./logger --stderr test with logger 2.26.39-eb651-dirty
<5>Mär 5 14:17:47 logger: test with logger 2.26.39-eb651-dirty
"Mär" like in German "März" for "March".
previously:
$ logger --stderr test with logger 2.25.2
rger: test with logger 2.25.2
In the system log file, this results to the following:
Mar 5 14:17:47 host Mär 5 14:17:47 logger: test with logger 2.26.39-eb651-dirty
Mar 5 14:18:01 host rger: test with logger 2.25.2
This local naming is invalid as of RFC3164. One may argue that
the local log socket traditionally does not have RFC3164 format,
but the timestamp always was as defined in RFC3164 (and along
the lines of the ctime() call). Anything else would also be impractical,
as a syslog parser would otherwise need to know about all
potential locale-specific representations of month names.
This patch corrects the problem and also refactors the timestamp
handling a bit. The same timestamp is needed in local and rfc3164
processing, so there now is a new function to create that stamp.
Rainer Gerhards [Wed, 4 Mar 2015 10:17:20 +0000 (11:17 +0100)]
logger: fix inconsistent format regression when logging locally
The message format when writing to local sockets is inconsistent. Example:
$ ./logger --stderr test
<5>Mär 4 11:03:30 logger: test
$ ./logger -u /dev/log --stderr test
<5>1 2015-03-04T11:03:31.699841+0100 ubuntu1404esp rger - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="29000"] test
The regression was introduced with 4de2e8a03859aaab2c25dc98f33409cd28de6acc
As far as the commit comments and man page indicates, this was meant to affect
remote system logging only, but it also affects local logging when the -u
option is given.
This causes problems with receivers who do not expect full-blown RFC format
on the log socket, like rsyslog. In consequence, this can also affect
log analysis programs and invalidate some of their results.
The patch corrects the behaviour so that the same old-style format is used for
any type of local logging. New-style can always be selected by command line-options.
RFC5424 is still the default for remote logging, as intended in the orignal
commit.
Result with the patch:
$ ./logger --stderr test
<5>Mär 4 11:15:35 logger: test
$ ./logger -u /dev/log --stderr test
<5>Mär 4 11:15:40 logger: test
$ ./logger -u /dev/log --rfc5424 --stderr test
<5>1 2015-03-04T11:21:28.796170+0100 ubuntu1404esp rger - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="27500"] test
The file /etc/os-release takes precedence over /usr/lib/os-release.
Applications should check for the former, and exclusively use its data
if it exists, and only fall back to /usr/lib/os-release if it is
missing.
Reported-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com> Signed-off-by: Karel Zak <kzak@redhat.com>
Peter Cordes [Wed, 25 Feb 2015 02:40:41 +0000 (22:40 -0400)]
docs: fstab(5) grammar / English fixes, and some other updates
I proofread the whole thing. I fixed everything that I thought could use
improvement.
various grammar and man page style-guide fixes (commas, word order, etc.).
Reworded a couple things to hopefully make it clear to someone that
didn't already know about fstab. Re-ordered the intro paragraphs
for easier skimming. And added an example line.
Expanded on a couple things other things.
Tightened up the wording in some other places to get the point across
faster and in less space.
Thanks to Benno Schulenberg <bensberg@justemail.net>
for several improvements.
Karel Zak [Wed, 25 Feb 2015 09:06:40 +0000 (10:06 +0100)]
build-sys: add --disable-colors-default
The current util-linux is to have enabled colorized outputs by
default, this default behavior is possible to change by new configure
option --disable-colors-default.
Karel Zak [Mon, 16 Feb 2015 11:49:49 +0000 (12:49 +0100)]
libmount: add --enable-libmount-force-mountinfo
The default libmount mtab management depends on mtan symlink. If the
symlink exists than libmount parses /proc/self/mountinfo, otherwise it
parses regular classic /etc/mtab. This is backwardly compatible and
transparent solution.
Unfortunately, this is not robust enough because some broken init
scripts or 3-party mount helpers may remove the symlink and create
regular mtab file. This is pretty bad if initd (systemd) depends on
libmount.
Fortunately we known that mtab is absolutely unwanted on some distros,
so it's fine too ignore mtab at all and don't care about the symlink.
Reported-by: Martin Pitt <martin.pitt@ubuntu.com> Signed-off-by: Karel Zak <kzak@redhat.com>
Sami Kerola [Sun, 15 Feb 2015 09:50:23 +0000 (09:50 +0000)]
logger: add --socket-errors compatibility option
Hello,
Depending viewpoint this change is either regression fix, or
re-regression in context of none-systemd init. I ack the change is sent
very late to be part of v2.26, but then again the excess noise was found
only because of -rc1 was tested in sysvinit environment. IMHO it would
contradict purpose of having rc's if faults will not lead to fixes.
I also want to point out the sysvinit scripts are broken, not the
logger(1), but getting them corrected is practically impossible.
Assuming sysvinit script are further developed by various teams and
distributions who maintain them they should use --socket-error=on in
future, and write scripts that pass without noise. Meanwhile trying to
be clever when to silence errors seems like a reasonable thing to do.
--->8----
From: Sami Kerola <kerolasa@iki.fi>
Date: Sat, 14 Feb 2015 19:05:55 +0000
Subject: [PATCH] logger: add --socket-errors compatibility option
Now when logger(1) has stopped using openlog() for Unix sockets, in
commit mentioned in reference, the lack of /dev/log detected will report
error accordingly. According to Gabriele Balducci this makes sysvinit
style boot scripts to print a lot of errors. So make the logger to
detect whether it should be in compatibility mode, and not report errors
if logging device is missing. That imitates behavior of glibc openlog().
To allow full control to users the /dev/log error messages can be forced
to on or off. The automatic error messaging is explained in manual page.
Sami Kerola [Sun, 8 Feb 2015 20:44:40 +0000 (20:44 +0000)]
rename: use strrchr() instead of rindex()
The rindex() is marked legacy in POSIX.1-2001, and apparently Androids
bionic libc does not even have it so it is best not to use the legacy
interface.
Reference: https://lists.gnu.org/archive/html/weechat-dev/2014-02/msg00004.html Signed-off-by: Sami Kerola <kerolasa@iki.fi>
I have found out that libmount does not respect MNT_OMODE_FORCE mode.
I don't see any usage in sources and libmount does not respect this mode
when calling library functions. I'm proposing a patch to fix this.
Sami Kerola [Tue, 3 Feb 2015 18:51:03 +0000 (18:51 +0000)]
fsck: use monotonic time to fsck run time measurement
Earlier use of gettimeofday() resulted to wrong measurement if system
administrator did manual time changes, or NTP or adjtime(3) adjusment
happen during fsck run.
projects / thirdparty / util-linux.git / log
