From owner-freebsd-current@freebsd.org Tue Jan 9 07:01:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64C31E67ED4 for ; Tue, 9 Jan 2018 07:01:41 +0000 (UTC) (envelope-from mykel@mware.ca) Received: from Vice.ServerNorth.net (vice.ServerNorth.net [209.44.123.194]) by mx1.freebsd.org (Postfix) with ESMTP id 43D906D58E for ; Tue, 9 Jan 2018 07:01:40 +0000 (UTC) (envelope-from mykel@mware.ca) Received: from mail.servernorth.net (localhost [127.0.0.1]) by Vice.ServerNorth.net (Postfix) with ESMTP id 882B056860 for ; Tue, 9 Jan 2018 02:01:33 -0500 (EST) Received: from mykel@mWare.ca by mail.servernorth.net (Archiveopteryx 3.1.4) with esmtpsa id 1515481291-19775-19773/9/1; Tue, 9 Jan 2018 02:01:31 -0500 Subject: Re: Make periodic's output log to files if sendmail is disabled on install To: freebsd-current@freebsd.org References: From: mykel@mware.ca Message-Id: Date: Tue, 9 Jan 2018 02:01:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 Mime-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA X-Mailman-Approved-At: Tue, 09 Jan 2018 11:50:21 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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: Tue, 09 Jan 2018 07:01:41 -0000 On 2018/01/08 00:34, Chris H wrote: > On Sun, 7 Jan 2018 23:05:44 -0500 said > >> 1) if sendmail is disabled during installation, have periodic's >> output logged to files (per example in >> https://www.freebsd.org/cgi/man.cgi?periodic(8) ) >> >> 2) make this the default anyway (logging to files), arguably the vast >> majority of systems' reporting is ignored :) >> At least now it could be logrotated out! > Hmm, if they are "arguably" already ignoring their system emails. Won't > they then *also* "arguably" ignore their [system] log files? > Why not just remove periodic etc/periodic(daily/weekly/monthly/security)? > But maybe I've just misunderstood the attempt here. But this way partitions don't get filled. Massive backlogs don't build, etc. Hence the logrotation benefit - the data's not permanently disposed of, but it's also not slowly killing a machine. You keep the benefit of the default periodic jobs. On 2018/01/08 10:26, Rodney W. Grimes wrote: >> 2) make this the default anyway (logging to files), arguably the vast >> majority of systems' reporting is ignored :) >> At least now it could be logrotated out! > You can argue that when you provide a statistical data set, > until then this is speculation at best and should not be used > in an argument for or against a change like this. Okay: In the ~300 machines I manage, 2 of them have their mailers set up to get those messages in front of an admin... and that's because those two machines are MTAs. The other 500+ FreeBSD installs I've done for clients are in the same boat... nobody wants more email, and no monitoring system is parsing the messages. (And who wants a passive monitoring system that only alerts daily?) Arguably having a machine years (or months!) down the road opaquely running out of disk is _not_ POLA. I'm not going to argue too hard for point #2, but I don't see how #1 is a bad idea: No MTA? Don't send emails. (Or create zillions of bounces.) On 2018/01/08 22:26, Mark Heily wrote: > I'm in favor of the suggestion of leaving the periodic cronjobs turned > off by default in the next release. Any existing automation is likely > geared towards turning those jobs off, and it would be trivial to turn > them back on again. As long as user-visible changes are documented > in the release notes, and users have an easy way to override the default, I > am all for providing a cleaner and simpler out of box experience. Arguably turning off periodic is far more disruptive than rendering it's output useful. I also think changing the output to logfiles (in absence of an MTA) is much better POLA than the 'new' offer of nuking /tmp on reboot; while it is an option, it's far more dangerous to delete data than not fill a disk with cruft. Myke