Luckily i'm not getting core dumps, so i cannot test, but why you recompiled systemd to disable a feature instead of conguring it at runtime to do the same?
...what's wrong with this?
# cat /etc/sysctl.d/60-coredump.conf kernel.core_pattern = core
I did it initially to test out lz4, and then I saw about 20 other things I could disable! It's only to keep me going until glibc2.20 is out then I'm starting again (getting rid of systemd in the process)
]]>...what's wrong with this?
# cat /etc/sysctl.d/60-coredump.conf
kernel.core_pattern = core
The warning is now fixed and the cpu usage is a duplicate of https://bugs.archlinux.org/task/41721, so neither are reasons to keep your report open.
I don't mind it's closed, it makes no difference to me.
That being said, FYI, or in case anyone else is reading this and has the same problem - LZ4 does not fix the Arch systemd (so it's not a dupe of that "feature request").
I just recompiled systemd and cut out most of the stuff I didn't need (including coredump). Result: problem gone.
]]>Irrespective of whether this is "intended to happen" or not - there is still a bug with cpu usage & also the fact the post-install warning is not shown due to a mistake in the install script.
How is that shooting yourself in the foot?
If it hadn't been closed, I'd have made every effort to help diagnose and/or fix it.
The warning is now fixed and the cpu usage is a duplicate of https://bugs.archlinux.org/task/41721, so neither are reasons to keep your report open.
]]>Irrespective of whether this is "intended to happen" or not - there is still a bug with cpu usage & also the fact the post-install warning is not shown due to a mistake in the install script.
How is that shooting yourself in the foot?
If it hadn't been closed, I'd have made every effort to help diagnose and/or fix it.
You can still do that.
FWIW the post_upgrade message is in testing.
]]>How is that shooting yourself in the foot?
If it hadn't been closed, I'd have made every effort to help diagnose and/or fix it.
]]>> The bug report makes it pretty clear the issue isn't with the Arch developers or with systemd, but with (surprise) your browsers.
No, the bug report makes it pretty clear that some softwares haves issue who created coredump, BUT ALSO, make it clear that something else has happened with a recent update of systemd, who make the log creation eating much more CPU (may be more evident on cheap computer)
If we look at the different bug report, we see that the solution given by Dev are "You could disable coredump creation", or "stopping to use software who create dump".
Fact is, since recent update, this coredump creation seems to eat much more CPU, and hang the system for a while. Dev's could argue that the first thing to do is to fix software issue (and this is a good idea), we could presume that those software issue happened all the time, long before we facing this CPU issue.
Closing bug report without trying to exclude a recent systemd issue (OR a new feature/behaviour with some side effect) is not a good answer.
Regards,
]]>Well, apparently freezing your system and filling your rootfs without warning is not a bug...
Great timing by the way Arch devs - I was literally minutes away from installing the lz4 enabled version (as requested for testing the effects on CPU usage)
"Shot yourselves in the foot" once again!
This is either a spectacularly poorly executed attempt at humour or a troll. The bug report makes it pretty clear the issue isn't with the Arch developers or with systemd, but with (surprise) your browsers.
Reflect for a minute on the fact that however smart you think you are, you aren't the person giving up your spare time as an Arch developer, your name isn't in any of the upstream contributor lists and while posting snide comments here may inflate your own sense of superiority, it doesn't contribute anything to this community; ergo it isn't welcome.
]]>Great timing by the way Arch devs - I was literally minutes away from installing the lz4 enabled version (as requested for testing the effects on CPU usage)
"Shot yourselves in the foot" once again!
The factual accuracy of this article or section is disputed.
Reason: /etc/sysctl.d overwrite files of the same name, however 50-coredump.conf is no longer present in Arch; journal dump behaviour is regulated in /etc/systemd/coredump.conf [2]. Core dumps are by default not written to the journal, but to /var/lib/systemd/coredump.
50-coredump.conf is no longer present in Arch? It was present on my install. O.o
]]>EDIT: Removing /usr/lib/sysctl.d/50-coredump.conf should do it, right?
It's worth noting that generally for systemd stuff, you can disable a systemd-installed file by symlinking /dev/null to a file of the same name inside a folder of the same name inside /etc. This has the advantage of not having a systemd upgrade bringing back the files you removed. (Admittedly, pacman.conf's NoExtract option would also work but there's only so much you can easily maintain on one line. ). In this case:
sudo ln -s /dev/null /etc/sysctl.d/50-coredump.conf
That said, I'll be doing what branch said (thanks!), as disabling the 50-coredump.conf rule leaves kernel.core_pattern set to core.
]]># /etc/sysctl.d/60-coredump.conf
kernel.core_pattern = /dev/null
*edit*
Note that cutting systemd-coredump out of the loop in this manner will prevent the core dump event from being logged.
[Coredump]
Storage=none
doesn't prevents the dumps from getting generated, it just deletes them immediately (I can see this in Dolphin). How can I turn this completely off?!
@Pse: I don't understand what "sudo systctl -w kernel.core_pattern=core" should help, this just specifies the name of the dump files, am I right?
EDIT: Removing /usr/lib/sysctl.d/50-coredump.conf should do it, right?
But before I would like to take a look into the mess. ...But how? I just know journalctl. Are these dumps just memory dumps or is there any more information for a layman in them?