From owner-freebsd-current@freebsd.org Sun May 19 08:55:15 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 308BC15A8126 for ; Sun, 19 May 2019 08:55:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79F7085583; Sun, 19 May 2019 08:55:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x4J8t180075992 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 19 May 2019 11:55:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x4J8t180075992 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x4J8t1X0075990; Sun, 19 May 2019 11:55:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 19 May 2019 11:55:01 +0300 From: Konstantin Belousov To: Rick Macklem Cc: Alan Somers , "freebsd-current@FreeBSD.org" Subject: Re: RFC w.r.t. toggling debugging on/off for mountd via a signal Message-ID: <20190519085501.GL2748@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2019 08:55:15 -0000 On Sun, May 19, 2019 at 02:47:10AM +0000, Rick Macklem wrote: > Alan Somers wrote: > >On Sat, May 18, 2019 at 7:59 PM Rick Macklem wrote: > >> > >> Hi, > >> > >> I've been working with Peter Errikson on a patch for mountd that adds a new option > >> for incremental updating of exports. This seems to be helping a lot w.r.t. performance > >> on an NFS server with lots (10000+) of exported file systems. > >> > >> I have debug syslog() calls in the code, which I/Peter think would be worth keeping > >> in the production code in case someone runs into problems with this new option. > >> > >> As such, I'd like to have the code compiled in by default (not only if DEBUG is defined, > >> as mountd.c has now). I also was thinking it would be nice if the daemon didn't need > >> to be restarted to enable/disable the debugging output, since that breaks NFS > >> mounting during the restart. > >> > >> So, I was thinking of having the debugging output toggled on/off via SIGUSR1. > >> > >> What do you think of this idea? > >> Any other/better ways to do this? > >> Also, would LOG_DAEMON and LOG_DEBUG sound like the correct facility and > >> priority for theses syslog() calls? > >> > >> Thanks in advance for any comments, rick > > > >If the debug messages aren't so verbose that they'll slow down > >syslogd, then you can just leave them enabled all the time. syslogd > >will filter them. However, if they're super-verbose then SIGUSR1 > >sounds reasonable. I can't think of another daemon with runtime > >selectable logging verbosity like that. > Yes, these are pretty chatty. 5-10 lines for each entry in an exports file. > Multiply that times the number of entries. (Peter's servers are between 20000 > to 72000+ file systems. Not sure if he has multiple entries/file system.) > > To give you a clue, without this patch, it can take 20sec->over 1min to reload them > when mountd gets a SIGHUP. > > It's just that the export file handling code is pretty convoluted, so I think the patch > is ok, but I won't be too surprised if someone finds a problem. Instead of toggling the debugging by SIGUSR1, you can make the daemon to try to open some file by receiving the normal reload signal, e.g. /var/run/mountd.debug. If the file is present, the debugging is enabled. The advantage is that the user knows what is the debugging state, instead of requiring to count the number of sent SIGUSR1's. More, in traditions of malloc(3), /var/run/mountd.debug could be a symlink, which is read and interpreted as some options controlling the debug.