teknoraver / rpms / systemd

Forked from rpms/systemd 3 months ago
Clone

Blame SOURCES/0226-core-try-to-reopen-dev-kmsg-again-right-after-mounti.patch

b9a53a
From 985837dab9c892858a92ae50043843307f5e0714 Mon Sep 17 00:00:00 2001
b9a53a
From: Lennart Poettering <lennart@poettering.net>
b9a53a
Date: Fri, 19 Jul 2019 18:29:11 +0200
b9a53a
Subject: [PATCH] core: try to reopen /dev/kmsg again right after mounting /dev
b9a53a
b9a53a
I was debugging stuff during early boot, and was confused that I never
b9a53a
found the logs for it in kmsg. The reason for that was that /proc is
b9a53a
generally not mounted the first time we do log_open() and hence
b9a53a
log_set_target(LOG_TARGET_KMSG) we do when running as PID 1 had not
b9a53a
effect. A lot later during start-up we call log_open() again where this
b9a53a
is fixed (after the point where we close all remaining fds still open),
b9a53a
but in the meantime no logs every got written to kmsg. This patch fixes
b9a53a
that.
b9a53a
b9a53a
(cherry picked from commit 0a2eef1ee1fef74be9d12f7dc4d0006b645b579c)
b9a53a
b9a53a
Resolves: #1749212
b9a53a
---
b9a53a
 src/core/main.c | 5 +++++
b9a53a
 1 file changed, 5 insertions(+)
b9a53a
b9a53a
diff --git a/src/core/main.c b/src/core/main.c
b9a53a
index 44dd8348be..af7b26d6f1 100644
b9a53a
--- a/src/core/main.c
b9a53a
+++ b/src/core/main.c
b9a53a
@@ -2215,6 +2215,11 @@ int main(int argc, char *argv[]) {
b9a53a
                                         goto finish;
b9a53a
                                 }
b9a53a
 
b9a53a
+                                /* Let's open the log backend a second time, in case the first time didn't
b9a53a
+                                 * work. Quite possibly we have mounted /dev just now, so /dev/kmsg became
b9a53a
+                                 * available, and it previously wasn't. */
b9a53a
+                                log_open();
b9a53a
+
b9a53a
                                 r = initialize_security(
b9a53a
                                                 &loaded_policy,
b9a53a
                                                 &security_start_timestamp,