overlay/05core: Set systemd LogColor=false #1079
Conversation
|
The other approach is to have the log parsers understand ANSI color. GitHub Actions has gone that route, for example. |
That'd be nice, but I think there are two major differences:
|
|
For reference, Amazon Linux boots with |
|
Is the problem slurped console logs or is it the process running I'd prefer not to differ from other Fedora editions here if we don't really need to. |
which I guess is different from |
This is a good point. But note: I think this is a server-versus-desktop thing, not a CoreOS versus "baseline Fedora" thing - i.e. Fedora Server or Cloud would likely want this too. I think in some perhaps distant future I could imagine somehow sharing code like this across editions. (OK well honestly, desktop systems should have silent or GUI boot with |
|
(Let's avoid implicitly saying we're not Fedora by contrasting with "Fedora". Instead, e.g. "other Fedora editions" is a good phrase) |
This. |
I agree. We need a way to share code across editions within similar categories.
I'm cool with starting here and propagating elsewhere, but I don't often see the "propagate elsewhere" happen. Which means we become more snowflake by the day. There are two ways to combat that:
Without something in place it just become "itch scratched" and we're off to the next thing.
👍 - I updated the comment to use that phrasing. |
Agree. It's tricky since there's just no easy way to share code right now. But...hmmm...maybe we could try to "roll up" PRs like this periodically into something like a Fedora Change? It clearly merits release notes of some form. |
|
Okay, this makes sense to me. If we're going this route, it seems like we should also:
|
|
OK I thought this was working in the initramfs, but it turns out that the way I was testing via |
We deploy on servers. The ANSI colors codes in the console output often end up in e.g. log files where they both make the logs hard to read *and* they make log files invalid UTF-8. This file needs to be created in both the real root and the initramfs, so extend our `99journald-conf` to be `99systemd-conf`.
|
|
Also suppress colors here since `journalctl` defaults to coloring if it thinks it can, and the way we're explicitly forwarding the journal bypasses the logic for systemd's default console coloring that we inject via default config. (Long term, I think it would make sense probably to move this "failed in the initramfs" handling into systemd itself and not be in custom shell script we carry)
|
Fixed that: |
Hmm, right. I will look at this. That said, this is an area where I'd argue we do want some platform specifics, because e.g. |
|
OK I verified that this works in AWS: Then |
Right, that would tie in with coreos/fedora-coreos-tracker#110. |
|
I'm still kind of torn on this. As a human who often (almost every weekday of my life) looks at serial console and VGA console (not just the logs but the actual console) for debugging FCOS the difference between the two screenshots is quite the regression (even though we're only getting the color because we're calling journalctl the wrong way). I do see the value, just wish there was a better way. |
|
Agree, though I think there's two factors here:
|
|
Though, one thing I should mention here is that I have a moderate red-green color blindness, which I am sure affects my opinion on the utility of colors - particularly the use of red here. As I understand it, the red appears much darker to me than it does to people with normal color vision. But it's not uncommon, and a standard in UI/UX design is to avoid requiring or over-using colors as a mechanism to distinguish between things. |
maybe a "non-gui" fedora-release subpackage? then we'd roll up changes every fedora release as a change and discuss amongst the other editions (cloud, server, iot, etc) that would be affected. For example we'd queue up changes like this, have a discussion and then get them in the next fedora release (of course we can prematurely apply them assuming discussion goes well). We can also choose to adopt a change any way if it provides enough benefit that we warrant carrying the change for just us. It would be really nice to have a plan for changes like this in the future. Otherwise over time this will be harder and harder to manage. to be clear: I am not intending to block this change, just using it for a sidebar discussion |
|
Should we re-discuss this at the next IRC meeting? |
seems reasonable. Want to open a top level tracker issue and tag it with |
We deploy on servers. The ANSI colors codes in the console
output often end up in e.g. log files where they both
make the logs hard to read and they make log files
invalid UTF-8.