How do I disable kernel logging into the systemd journal?
I'm using a device that spams kernel messages excessively (10-100 messages a second, Mediatek drivers...), where it is infeasible to remove the logging from the kernel itself (spread across hundreds of files).
I've accepted that dmesg is all but useless on this device, but unfortunately the systemd journal is also affected.
Is it possible to filter/disable logging kernel messages into the systemd journal?
linux kernel systemd
asked Jun 23 '18 at 14:31
Luke FLuke F
1491110
add a comment |
I'm using a device that spams kernel messages excessively (10-100 messages a second, Mediatek drivers...), where it is infeasible to remove the logging from the kernel itself (spread across hundreds of files).
I've accepted that dmesg is all but useless on this device, but unfortunately the systemd journal is also affected.
Is it possible to filter/disable logging kernel messages into the systemd journal?
linux kernel systemd
asked Jun 23 '18 at 14:31
Luke FLuke F
1491110
Instead of disabling the logging of kernel messages, I would investigate the reason why mediatek drivers produce such a high level of output and what can be done about it. Kernel messages are quite useful.
– MariusMatutiae
Jun 23 '18 at 16:57
I completely agree, but the output from these Mediatek drivers is just ridiculous. It spams several lines (of all available priorities) for things like turning on/off a CPU core or the battery voltage changing by a minuscule amount. There is no way to stop the spam that I can see, each driver uses its own hard-coded logging configuration, best I can do is comment out the worst culprits
– Luke F
Jun 23 '18 at 20:40
add a comment |
I'm using a device that spams kernel messages excessively (10-100 messages a second, Mediatek drivers...), where it is infeasible to remove the logging from the kernel itself (spread across hundreds of files).
I've accepted that dmesg is all but useless on this device, but unfortunately the systemd journal is also affected.
Is it possible to filter/disable logging kernel messages into the systemd journal?
linux kernel systemd
asked Jun 23 '18 at 14:31
Luke FLuke F
1491110
I'm using a device that spams kernel messages excessively (10-100 messages a second, Mediatek drivers...), where it is infeasible to remove the logging from the kernel itself (spread across hundreds of files).
I've accepted that dmesg is all but useless on this device, but unfortunately the systemd journal is also affected.
Is it possible to filter/disable logging kernel messages into the systemd journal?
linux kernel systemd
linux kernel systemd
asked Jun 23 '18 at 14:31
Luke FLuke F
1491110
asked Jun 23 '18 at 14:31
Luke FLuke F
1491110
asked Jun 23 '18 at 14:31
Luke FLuke F
1491110
asked Jun 23 '18 at 14:31
Luke FLuke F
1491110
asked Jun 23 '18 at 14:31
Luke FLuke F
1491110
1491110
Instead of disabling the logging of kernel messages, I would investigate the reason why mediatek drivers produce such a high level of output and what can be done about it. Kernel messages are quite useful.
– MariusMatutiae
Jun 23 '18 at 16:57
I completely agree, but the output from these Mediatek drivers is just ridiculous. It spams several lines (of all available priorities) for things like turning on/off a CPU core or the battery voltage changing by a minuscule amount. There is no way to stop the spam that I can see, each driver uses its own hard-coded logging configuration, best I can do is comment out the worst culprits
– Luke F
Jun 23 '18 at 20:40
add a comment |
Instead of disabling the logging of kernel messages, I would investigate the reason why mediatek drivers produce such a high level of output and what can be done about it. Kernel messages are quite useful.
– MariusMatutiae
Jun 23 '18 at 16:57
I completely agree, but the output from these Mediatek drivers is just ridiculous. It spams several lines (of all available priorities) for things like turning on/off a CPU core or the battery voltage changing by a minuscule amount. There is no way to stop the spam that I can see, each driver uses its own hard-coded logging configuration, best I can do is comment out the worst culprits
– Luke F
Jun 23 '18 at 20:40
Instead of disabling the logging of kernel messages, I would investigate the reason why mediatek drivers produce such a high level of output and what can be done about it. Kernel messages are quite useful.
– MariusMatutiae
Jun 23 '18 at 16:57
Instead of disabling the logging of kernel messages, I would investigate the reason why mediatek drivers produce such a high level of output and what can be done about it. Kernel messages are quite useful.
– MariusMatutiae
Jun 23 '18 at 16:57
I completely agree, but the output from these Mediatek drivers is just ridiculous. It spams several lines (of all available priorities) for things like turning on/off a CPU core or the battery voltage changing by a minuscule amount. There is no way to stop the spam that I can see, each driver uses its own hard-coded logging configuration, best I can do is comment out the worst culprits
– Luke F
Jun 23 '18 at 20:40
I completely agree, but the output from these Mediatek drivers is just ridiculous. It spams several lines (of all available priorities) for things like turning on/off a CPU core or the battery voltage changing by a minuscule amount. There is no way to stop the spam that I can see, each driver uses its own hard-coded logging configuration, best I can do is comment out the worst culprits
– Luke F
Jun 23 '18 at 20:40
add a comment |
2 Answers
2
active
oldest
votes
Good Linux/Sysadmin practice would recommend you go with something like fzbd's solution in which you're silencing the specific log you don't need to see rather than disabling kernel messages wholesale.
Nevertheless, it's still worth mentioning that as of systemd 235, there's an option for disabling kernel messages within journald.conf file. The main journal.conf docs mention this option which allows you to disable journald from reading /dev/kmsg.
Version 235 may not be found in many distributions just yet, so you can check your systemd version with:
systemctl --version
If you have version 235 or above you can proceed by first making a backup of the original /etc/systemd/journald.conf file and then uncommenting the relevant line and changing it from yes to no:
ReadKMsg=no
Save, exit, and restart your journald service:
sudo systemctl restart systemd-journald.service
answered Jun 23 '18 at 16:15
baelxbaelx
1,807817
1
Many thanks, installed systemd from stretch-backports and ReadKMsg=no did the trick!
– Luke F
Jun 23 '18 at 22:12
Instead of edit /etc/systemd/journald.conf it is better to override it with /etc/systemd/journald.conf.d/kfilter.conf (for example).
– Oleg Kr
Sep 21 '18 at 7:32
@Oleg Yeah, making things more modular is usually a good practice when possible, so yes that’d also a great option.
– baelx
Sep 22 '18 at 19:33
add a comment |
See if your device's kernel module has some logging/debug parameter which you can disable:
modprobe $module_name
ls /sys/module/$module_name/parameters
If not, for systemd with version < 235, the best you can do is filter messages by log level, for example:
journalctl --priority=3
You can check the log values with man syslog.
Note that lowering the kernel logging levels using kernel.printk only affects console logging, so userland applications will still show the same messages, regardless of the values in this parameter.
answered Jun 23 '18 at 15:41
fzbdfzbd
1312
As far as I know kernel.printk only affects kernel logging to TTYs? Sadly there are no exposed parameters for the drivers responsible for the spam
– Luke F
Jun 23 '18 at 20:44
You are right, calls to printk() still show up on journalctl. I've revised my answer.
– fzbd
Jun 24 '18 at 9:33
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1333674%2fhow-do-i-disable-kernel-logging-into-the-systemd-journal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Good Linux/Sysadmin practice would recommend you go with something like fzbd's solution in which you're silencing the specific log you don't need to see rather than disabling kernel messages wholesale.
Nevertheless, it's still worth mentioning that as of systemd 235, there's an option for disabling kernel messages within journald.conf file. The main journal.conf docs mention this option which allows you to disable journald from reading /dev/kmsg.
Version 235 may not be found in many distributions just yet, so you can check your systemd version with:
systemctl --version
If you have version 235 or above you can proceed by first making a backup of the original /etc/systemd/journald.conf file and then uncommenting the relevant line and changing it from yes to no:
ReadKMsg=no
Save, exit, and restart your journald service:
sudo systemctl restart systemd-journald.service
answered Jun 23 '18 at 16:15
baelxbaelx
1,807817
1
Many thanks, installed systemd from stretch-backports and ReadKMsg=no did the trick!
– Luke F
Jun 23 '18 at 22:12
Instead of edit /etc/systemd/journald.conf it is better to override it with /etc/systemd/journald.conf.d/kfilter.conf (for example).
– Oleg Kr
Sep 21 '18 at 7:32
@Oleg Yeah, making things more modular is usually a good practice when possible, so yes that’d also a great option.
– baelx
Sep 22 '18 at 19:33
add a comment |
Good Linux/Sysadmin practice would recommend you go with something like fzbd's solution in which you're silencing the specific log you don't need to see rather than disabling kernel messages wholesale.
Nevertheless, it's still worth mentioning that as of systemd 235, there's an option for disabling kernel messages within journald.conf file. The main journal.conf docs mention this option which allows you to disable journald from reading /dev/kmsg.
Version 235 may not be found in many distributions just yet, so you can check your systemd version with:
systemctl --version
If you have version 235 or above you can proceed by first making a backup of the original /etc/systemd/journald.conf file and then uncommenting the relevant line and changing it from yes to no:
ReadKMsg=no
Save, exit, and restart your journald service:
sudo systemctl restart systemd-journald.service
answered Jun 23 '18 at 16:15
baelxbaelx
1,807817
1
Many thanks, installed systemd from stretch-backports and ReadKMsg=no did the trick!
– Luke F
Jun 23 '18 at 22:12
Instead of edit /etc/systemd/journald.conf it is better to override it with /etc/systemd/journald.conf.d/kfilter.conf (for example).
– Oleg Kr
Sep 21 '18 at 7:32
@Oleg Yeah, making things more modular is usually a good practice when possible, so yes that’d also a great option.
– baelx
Sep 22 '18 at 19:33
add a comment |
Good Linux/Sysadmin practice would recommend you go with something like fzbd's solution in which you're silencing the specific log you don't need to see rather than disabling kernel messages wholesale.
Nevertheless, it's still worth mentioning that as of systemd 235, there's an option for disabling kernel messages within journald.conf file. The main journal.conf docs mention this option which allows you to disable journald from reading /dev/kmsg.
Version 235 may not be found in many distributions just yet, so you can check your systemd version with:
systemctl --version
If you have version 235 or above you can proceed by first making a backup of the original /etc/systemd/journald.conf file and then uncommenting the relevant line and changing it from yes to no:
ReadKMsg=no
Save, exit, and restart your journald service:
sudo systemctl restart systemd-journald.service
answered Jun 23 '18 at 16:15
baelxbaelx
1,807817
Good Linux/Sysadmin practice would recommend you go with something like fzbd's solution in which you're silencing the specific log you don't need to see rather than disabling kernel messages wholesale.
Nevertheless, it's still worth mentioning that as of systemd 235, there's an option for disabling kernel messages within journald.conf file. The main journal.conf docs mention this option which allows you to disable journald from reading /dev/kmsg.
Version 235 may not be found in many distributions just yet, so you can check your systemd version with:
systemctl --version
If you have version 235 or above you can proceed by first making a backup of the original /etc/systemd/journald.conf file and then uncommenting the relevant line and changing it from yes to no:
ReadKMsg=no
Save, exit, and restart your journald service:
sudo systemctl restart systemd-journald.service
answered Jun 23 '18 at 16:15
baelxbaelx
1,807817
edited Feb 9 at 23:44
answered Jun 23 '18 at 16:15
baelxbaelx
1,807817
answered Jun 23 '18 at 16:15
baelxbaelx
1,807817
answered Jun 23 '18 at 16:15
baelxbaelx
1,807817
1,807817
1
Many thanks, installed systemd from stretch-backports and ReadKMsg=no did the trick!
– Luke F
Jun 23 '18 at 22:12
Instead of edit /etc/systemd/journald.conf it is better to override it with /etc/systemd/journald.conf.d/kfilter.conf (for example).
– Oleg Kr
Sep 21 '18 at 7:32
@Oleg Yeah, making things more modular is usually a good practice when possible, so yes that’d also a great option.
– baelx
Sep 22 '18 at 19:33
add a comment |
1
Many thanks, installed systemd from stretch-backports and ReadKMsg=no did the trick!
– Luke F
Jun 23 '18 at 22:12
Instead of edit /etc/systemd/journald.conf it is better to override it with /etc/systemd/journald.conf.d/kfilter.conf (for example).
– Oleg Kr
Sep 21 '18 at 7:32
@Oleg Yeah, making things more modular is usually a good practice when possible, so yes that’d also a great option.
– baelx
Sep 22 '18 at 19:33
1
1
Many thanks, installed systemd from stretch-backports and ReadKMsg=no did the trick!
– Luke F
Jun 23 '18 at 22:12
Many thanks, installed systemd from stretch-backports and ReadKMsg=no did the trick!
– Luke F
Jun 23 '18 at 22:12
Instead of edit /etc/systemd/journald.conf it is better to override it with /etc/systemd/journald.conf.d/kfilter.conf (for example).
– Oleg Kr
Sep 21 '18 at 7:32
Instead of edit /etc/systemd/journald.conf it is better to override it with /etc/systemd/journald.conf.d/kfilter.conf (for example).
– Oleg Kr
Sep 21 '18 at 7:32
@Oleg Yeah, making things more modular is usually a good practice when possible, so yes that’d also a great option.
– baelx
Sep 22 '18 at 19:33
@Oleg Yeah, making things more modular is usually a good practice when possible, so yes that’d also a great option.
– baelx
Sep 22 '18 at 19:33
add a comment |
See if your device's kernel module has some logging/debug parameter which you can disable:
modprobe $module_name
ls /sys/module/$module_name/parameters
If not, for systemd with version < 235, the best you can do is filter messages by log level, for example:
journalctl --priority=3
You can check the log values with man syslog.
Note that lowering the kernel logging levels using kernel.printk only affects console logging, so userland applications will still show the same messages, regardless of the values in this parameter.
answered Jun 23 '18 at 15:41
fzbdfzbd
1312
As far as I know kernel.printk only affects kernel logging to TTYs? Sadly there are no exposed parameters for the drivers responsible for the spam
– Luke F
Jun 23 '18 at 20:44
You are right, calls to printk() still show up on journalctl. I've revised my answer.
– fzbd
Jun 24 '18 at 9:33
add a comment |
See if your device's kernel module has some logging/debug parameter which you can disable:
modprobe $module_name
ls /sys/module/$module_name/parameters
If not, for systemd with version < 235, the best you can do is filter messages by log level, for example:
journalctl --priority=3
You can check the log values with man syslog.
Note that lowering the kernel logging levels using kernel.printk only affects console logging, so userland applications will still show the same messages, regardless of the values in this parameter.
answered Jun 23 '18 at 15:41
fzbdfzbd
1312
As far as I know kernel.printk only affects kernel logging to TTYs? Sadly there are no exposed parameters for the drivers responsible for the spam
– Luke F
Jun 23 '18 at 20:44
You are right, calls to printk() still show up on journalctl. I've revised my answer.
– fzbd
Jun 24 '18 at 9:33
add a comment |
See if your device's kernel module has some logging/debug parameter which you can disable:
modprobe $module_name
ls /sys/module/$module_name/parameters
If not, for systemd with version < 235, the best you can do is filter messages by log level, for example:
journalctl --priority=3
You can check the log values with man syslog.
Note that lowering the kernel logging levels using kernel.printk only affects console logging, so userland applications will still show the same messages, regardless of the values in this parameter.
answered Jun 23 '18 at 15:41
fzbdfzbd
1312
See if your device's kernel module has some logging/debug parameter which you can disable:
modprobe $module_name
ls /sys/module/$module_name/parameters
If not, for systemd with version < 235, the best you can do is filter messages by log level, for example:
journalctl --priority=3
You can check the log values with man syslog.
Note that lowering the kernel logging levels using kernel.printk only affects console logging, so userland applications will still show the same messages, regardless of the values in this parameter.
answered Jun 23 '18 at 15:41
fzbdfzbd
1312
edited Jun 24 '18 at 9:37
answered Jun 23 '18 at 15:41
fzbdfzbd
1312
answered Jun 23 '18 at 15:41
fzbdfzbd
1312
answered Jun 23 '18 at 15:41
fzbdfzbd
1312
1312
As far as I know kernel.printk only affects kernel logging to TTYs? Sadly there are no exposed parameters for the drivers responsible for the spam
– Luke F
Jun 23 '18 at 20:44
You are right, calls to printk() still show up on journalctl. I've revised my answer.
– fzbd
Jun 24 '18 at 9:33
add a comment |
As far as I know kernel.printk only affects kernel logging to TTYs? Sadly there are no exposed parameters for the drivers responsible for the spam
– Luke F
Jun 23 '18 at 20:44
You are right, calls to printk() still show up on journalctl. I've revised my answer.
– fzbd
Jun 24 '18 at 9:33
As far as I know kernel.printk only affects kernel logging to TTYs? Sadly there are no exposed parameters for the drivers responsible for the spam
– Luke F
Jun 23 '18 at 20:44
As far as I know kernel.printk only affects kernel logging to TTYs? Sadly there are no exposed parameters for the drivers responsible for the spam
– Luke F
Jun 23 '18 at 20:44
You are right, calls to printk() still show up on journalctl. I've revised my answer.
– fzbd
Jun 24 '18 at 9:33
You are right, calls to printk() still show up on journalctl. I've revised my answer.
– fzbd
Jun 24 '18 at 9:33
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1333674%2fhow-do-i-disable-kernel-logging-into-the-systemd-journal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Instead of disabling the logging of kernel messages, I would investigate the reason why mediatek drivers produce such a high level of output and what can be done about it. Kernel messages are quite useful.
– MariusMatutiae
Jun 23 '18 at 16:57
I completely agree, but the output from these Mediatek drivers is just ridiculous. It spams several lines (of all available priorities) for things like turning on/off a CPU core or the battery voltage changing by a minuscule amount. There is no way to stop the spam that I can see, each driver uses its own hard-coded logging configuration, best I can do is comment out the worst culprits
– Luke F
Jun 23 '18 at 20:40