linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).