From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: sandeen@redhat.com, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/7] xfs_scrub: log operational messages when interactive
Date: Tue, 13 Feb 2018 16:39:28 -0800 [thread overview]
Message-ID: <20180214003928.GG5217@magnolia> (raw)
In-Reply-To: <d32e8c99-5a56-6409-ec42-aea01220e2f7@sandeen.net>
On Mon, Feb 12, 2018 at 02:47:14PM -0600, Eric Sandeen wrote:
> On 2/5/18 5:22 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > Record the output of an interactive session in the system log so that
> > future support requests can get a better picture of what happened.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
>
> I really want to log things, but I'm conflicted about spamming syslog.
> I'm wondering if a generic /var/log/xfs.log would be good, and it could
> eventually log all xfs-related administrative actions and outcomes with
> a libfrog library helper... I don't know how non-syslog log files are
> handled in general, does everybody just roll their own?
Evidently rsyslog actually can filter things out to a separate file.
For example, /etc/rsyslog.d/20-ufw.conf:
# Log kernel generated UFW log messages to file
:msg,contains,"[UFW " /var/log/ufw.log
# Uncomment the following to stop logging anything that matches the last
# rule. Doing this will stop logging kernel generated UFW log messages
# to the file normally containing kern.* messages (eg,
# /var/log/kern.log)
#& stop
Therefore, it looks as though we actually /can/ use the regular syslog
calls from various xfs utilities and (if rsyslog is up) forward the
output to a place where support can capture it later.
--D
>
> I'm inclined to leave this one out of 4.15 for now while I/we think
> about the big picture here.
>
> -Eric
>
> > ---
> > scrub/common.c | 37 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> >
> > diff --git a/scrub/common.c b/scrub/common.c
> > index 17c3699..672f286 100644
> > --- a/scrub/common.c
> > +++ b/scrub/common.c
> > @@ -21,6 +21,7 @@
> > #include <pthread.h>
> > #include <stdbool.h>
> > #include <sys/statvfs.h>
> > +#include <syslog.h>
> > #include "platform_defs.h"
> > #include "xfs.h"
> > #include "xfs_fs.h"
> > @@ -29,6 +30,8 @@
> > #include "common.h"
> > #include "progress.h"
> >
> > +extern char *progname;
> > +
> > /*
> > * Reporting Status to the Console
> > *
> > @@ -64,6 +67,12 @@ static const char *err_str[] = {
> > [S_PREEN] = "Optimized",
> > };
> >
> > +static int log_level[] = {
> > + [S_ERROR] = LOG_ERR,
> > + [S_WARN] = LOG_WARNING,
> > + [S_INFO] = LOG_INFO,
> > +};
> > +
> > /* If stream is a tty, clear to end of line to clean up progress bar. */
> > static inline const char *stream_start(FILE *stream)
> > {
> > @@ -73,6 +82,8 @@ static inline const char *stream_start(FILE *stream)
> > }
> >
> > /* Print a warning string and some warning text. */
> > +#define LOG_BUFSZ 4096
> > +#define LOGNAME_BUFSZ 256
> > void
> > __str_out(
> > struct scrub_ctx *ctx,
> > @@ -110,6 +121,32 @@ __str_out(
> > va_end(args);
> > }
> >
> > + /* If we're running interactively, log the message to syslog too. */
> > + if (isatty(fileno(stdin)) && !debug) {
> > + char logname[LOGNAME_BUFSZ];
> > +
> > + snprintf(logname, LOGNAME_BUFSZ, "%s@%s", progname,
> > + ctx->mntpoint);
> > + openlog(logname, LOG_PID, LOG_DAEMON);
> > +
> > + if (error) {
> > + syslog(LOG_ERR, "%s: %s: %s.",
> > + _(err_str[level]), descr,
> > + strerror_r(error, buf, DESCR_BUFSZ));
> > + } else {
> > + char buf[LOG_BUFSZ];
> > + int sz;
> > +
> > + sz = snprintf(buf, LOG_BUFSZ, "%s: %s: ",
> > + _(err_str[level]), descr);
> > + va_start(args, format);
> > + vsnprintf(buf + sz, LOG_BUFSZ - sz, format, args);
> > + va_end(args);
> > + syslog(log_level[level], "%s", buf);
> > + }
> > + closelog();
> > + }
> > +
> > if (debug)
> > fprintf(stream, _(" (%s line %d)"), file, line);
> > fprintf(stream, "\n");
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-02-14 0:39 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 23:22 [PATCH 0/7] xfsprogs: 4.15 rollup pt. 5 Darrick J. Wong
2018-02-05 23:22 ` [PATCH 1/7] xfs_scrub: log operational messages when interactive Darrick J. Wong
2018-02-12 20:47 ` Eric Sandeen
2018-02-14 0:39 ` Darrick J. Wong [this message]
2018-02-14 7:48 ` Jan Tulak
2018-02-14 16:51 ` Darrick J. Wong
2018-03-08 18:07 ` Darrick J. Wong
2018-03-08 18:27 ` Eric Sandeen
2018-02-14 7:50 ` Jan Tulak
2018-02-05 23:22 ` [PATCH 2/7] xfs_scrub: remove preen mode Darrick J. Wong
2018-02-12 20:49 ` Eric Sandeen
2018-02-12 23:57 ` Darrick J. Wong
2018-02-14 7:53 ` Jan Tulak
2018-02-05 23:22 ` [PATCH 3/7] xfs_scrub: classify lack of ioctl support as a runtime error Darrick J. Wong
2018-02-12 20:50 ` Eric Sandeen
2018-02-14 7:54 ` Jan Tulak
2018-02-05 23:22 ` [PATCH 4/7] xfs_scrub: reclassify runtime errors Darrick J. Wong
2018-02-12 20:52 ` Eric Sandeen
2018-02-14 7:56 ` Jan Tulak
2018-02-05 23:22 ` [PATCH 5/7] xfs_scrub: reclassify some of the warning messages Darrick J. Wong
2018-02-12 20:53 ` Eric Sandeen
2018-02-14 7:56 ` Jan Tulak
2018-02-05 23:23 ` [PATCH 6/7] xfs_scrub: always init phase information Darrick J. Wong
2018-02-12 20:53 ` Eric Sandeen
2018-02-14 7:57 ` Jan Tulak
2018-02-05 23:23 ` [PATCH 7/7] xfs_scrub: refactor outcome display into a separate helper Darrick J. Wong
2018-02-12 21:06 ` Eric Sandeen
2018-02-13 0:00 ` Darrick J. Wong
2018-02-14 7:59 ` Jan Tulak
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=20180214003928.GG5217@magnolia \
--to=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=sandeen@sandeen.net \
/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.
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).