linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Jan Tulak <jtulak@redhat.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
	Eric Sandeen <sandeen@redhat.com>,
	linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH 1/7] xfs_scrub: log operational messages when interactive
Date: Wed, 14 Feb 2018 08:51:16 -0800	[thread overview]
Message-ID: <20180214165116.GJ5217@magnolia> (raw)
In-Reply-To: <CACj3i738kNViGQz34BG69=FjwQYZkD1Aubg--WC4zTEdn8wt3g@mail.gmail.com>

On Wed, Feb 14, 2018 at 08:48:09AM +0100, Jan Tulak wrote:
> On Wed, Feb 14, 2018 at 1:39 AM, Darrick J. Wong
> <darrick.wong@oracle.com> wrote:
> > 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.
> >
> 
> I wanted to join Eric in this, but I didn't know about the filter
> rules, thanks for something new to learn. With such a rule, I'm all
> for syslog, and I'm attaching my first humble reviewed-by. :-)

The downside is that it also doesn't work, at least on the ubuntu 16.04
rsyslog (which is curious, since that's also where I got the 20-ufw.conf
file) so someone with better rsyslog-conf-fu will have to help us out
here.

--D

> Cheers,
> Jan
> 
> > --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
> > --
> > 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

  reply	other threads:[~2018-02-14 16:51 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
2018-02-14  7:48       ` Jan Tulak
2018-02-14 16:51         ` Darrick J. Wong [this message]
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=20180214165116.GJ5217@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=jtulak@redhat.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).