On Wed, 2018-06-20 at 13:15 -0400, Stephen Gallagher wrote: > On Wed, Jun 20, 2018 at 12:34 PM Gerald B. Cox <gbcox@xxxxxx> wrote: > > > This isn't related to a service, but is throwing out an spurious error > > message. There is a patch but it hasn't made it's way > > yet into the Fedora kernel: > > > > rt_cmos registration error: rhbz#1568276 > > Basically an error is being thrown because your system doesn't have > > battery backup. To their credit, it was quickly identified > > and patched. We now just have to wait for the patch to be applied. > > > > However these: > > > > The mcelog.service message is associated with rhbz#1166978 > > The dbxtool.service message is associated with rhbz#1508808 > > The rngd.service message is associated with rhbz#1490632 > > > > At least for me are the result of services being enabled by default, that > > should never have been enabled for my > > environment. > > > > mcelog: I am using an AMD processor. This service only applies to Intel. > > dbxtool: I am not using SecureBoot. This service only applies to > > machines using SecureBoot. > > rngd: I am not using a machine that has a hardware RNG generator > > > > Again, if we are apparently so concerned about a streamlined user > > experience, why are we > > starting processes that aren't needed - and in fact are not appropriate > > for a particular environment, > > and then throwing out error messages which are spurious and confusing? > > > > In my case, this caused me to spend hours individually tracking down all > > these error messages > > to find out that there is nothing wrong with my environment. Instead the > > issue is these services > > are inappropriately started for EVERYBODY - and in one case have been > > languishing for years. > > > > Last time I checked, Fedora wasn't an Intel only, SecureBoot only, > > mandatory hardware RNG generator > > environment. > > > > If we truly are concerned about end user experience - this isn't the way > > to go about it. > > > > > > The proper behavior here would be for these services not to be marked as > "failed" when the appropriate hardware is not present. When possible, we > should be using systemd's Condition* features to skip attempting to start > it at all, but for things where we can't know it ahead of time, we should > modify the start script to look for appropriate error codes/messages and > treat the service as "success" if it's skipped because it's not supported > on the current hardware. Well, for rngd, the maintainer actually argued that he does *not* think this is the "proper" behaviour. See https://bugzilla.redhat.com/show_bug.cgi?id=1490632#c11 . I don't agree with him (as you can, er, tell from the subsequent discussion), but it seemed worth noting it's not a universally agreed truth. (I don't *think* he'd object to a Condition-type fix, though, if we could come up with a reliable one). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/2DUGDLLLUTXTHFDWWOTMADJM3WS42RAC/
