Date: Tue, 9 Jan 2018 02:01:31 -0500 From: mykel@mware.ca To: freebsd-current@freebsd.org Subject: Re: Make periodic's output log to files if sendmail is disabled on install Message-ID: <d8b1947c-a4e5-858d-1818-9beec65e4b34@mware.ca> In-Reply-To: <cdefd35803d48d2aa21a2bbf9692d789@udns.ultimatedns.net> References: <cdefd35803d48d2aa21a2bbf9692d789@udns.ultimatedns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018/01/08 00:34, Chris H wrote: > On Sun, 7 Jan 2018 23:05:44 -0500 <mykel@mWare.ca> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d8b1947c-a4e5-858d-1818-9beec65e4b34>