On Sun, Mar 07, 2021 at 10:00:56AM +0100, Hans de Goede wrote: > Hi, > > On 3/5/21 4:17 PM, Matthew Miller wrote: > > On Fri, Mar 05, 2021 at 03:05:00PM +0100, Hans de Goede wrote: > >>> mcelog.service loaded active running Machine Check Exception Logging Daemon > >> This is another one for which it is questionable to have it running, or is this a machine with > >> ECC RAM ? And even then I'm not sure if it adds a lot of value, or if just like smartd it > >> just logs some stuff into syslog (where normal users won't see it). > > > > I disagree that those logs are useless -- I often help normal users, and > > running commands to look back in the logs for problems is a common > > diagnostic step. This could be better, of course. > > But for MCE exceptions, specifically ECC errors I would expect the kernel to log these > through dmesg anyways and then the mcelog service has very little added value IMHO > (I have no experience with machines with ECC RAM). It seems mce events can also be generated by the CPU. From the man page: data corruption detected in the CPU caches, in main memory by an integrated memory controller, data transfer errors on the front side bus or CPU interconnect or other internal errors. ... When an uncorrected machine check error happens that the kernel cannot recover from then it will usually panic the system. In this case when there was a warm reset after the panic mcelog should pick up the machine check errors after reboot. It seems like it could be useful even without ECC… > smartd at least has the fact that if it does not run nothing else is asking the > disk for its smart reports going for it (and that it may tickle bugs in some > disks, which otherwise would not be tickled, going against it). > > Note I still think smartd is of questionable value too, esp. as long as any > messages which it sends out only end up in the journal and are note pushed > to the user inside the UI in some way. As for the argument that it sends > email if local email delivery is setup, well we don't set that up OOTB and > this is about OOTB configuraiton, someone who can setup local email can > also do a "dnf install smartd". I think it's useful to have hardware errors logged, even if nobody immediately looks at them. If a laptop gets broken, and a more knowledgeable persons is asked to look at it and there are hardware errors in the log, be it from mce or smart, that is a very effective way to diagnose the issue and save a few hours wasted on trying to figure out an elusive bug. (This also applies to logs attached in bugzilla: especially when we had the service watchdog enabled, people would regularly report services "hanging". It seems many of those were caused by disk issues, and it's nice to have smartd in there.) In summary: in both cases, I think keeping mcelog and smartd (and other similar things) enabled by default is still useful. We should just make sure they quickly and quietly exit if not applicable on given hardware. Zbyszek > >> So given that I got a couple of "go for it" reactions and that I was > >> already toying with the idea anyways I might actually try to make such > >> a spin happen. > >> > >> The biggest problem for doing such a spin is finding the time for it... > >> > >> Are there any people who would be interested in working on / co-maintaining > >> such a spin with me ? > > > > I am interested in it happening but can't sign up for more stuff. :) > > I know the feeling. > > > It seems like this kind of parallels the Minimization objective (which > > focuses on package dependencies). That's kind of mothballed right now (I > > think because Adam is working on RHEL 9 stuff?) and I wouldn't want to > > overload that more, but maybe there's some kind of useful connection? > > This is more about runtime overhead, where as the Minimization objective > focuses more on pure disk-space consumption. Sure, there is some overlap > but not much. > > Regards, > > Hans > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
