valeriyvdovin / rpms / systemd

Forked from rpms/systemd 4 years ago
Clone

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

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