53 ms·

One major problem with systemd is that beta software is released as stable and incorporated in distros. I've just realized that systemd-coredumpd is used to sav

by cm3 11y ago

One major problem with systemd is that beta software is released as stable and incorporated in distros. I've just realized that systemd-coredumpd is used to save crashes in the journal and write the files somewhere to /var. This has the problem that I have to vacuum or nuke the journal if I want to remove knowledge of past crashes because coredumpctl tool has no delete command. And coredumpctl hard-codes GDB as the debugger. To fix all of this I've overwritten the systctl.d file and made it write somewhere I know and can find without the use of an unfinished tool. I have also regularly had it happen that bootup would intermittently hang up or shutdown as well. There are also unfixed warnings and errors during shutdown on multiple machines. My conclusion is that systemd uses the broader population for beta testing, even if you don't follow Fedora Rawhide or Arch rolling.

chris_wot 11y ago
Try setting Storage=external in coredump.conf [1] - you seem to have it set to both, which I have to agree is probably less than ideal. 1. https://www.freedesktop.org/software/systemd/man/coredump.conf.html https://www.freedesktop.org/software/systemd/man/coredump.co...
- cm3 11y ago
  Nope. I've scoured previous bug report and discussions and the only sure way was to prevent systemd from swallowing core dumps. It had the nice side effect that I learned the format string and configured it to my personal needs. But having to reverse engineer in order to remove crashes is not stable software and just a tech preview. If I wanted to be cynical, I'd believe anything coming out of systemd, regardless of quality, is accepted as the new way while discarding existing ways as obsolete. I should add to my startup hangup remark that I never before had a startup problem that was intermittent with plain old stupid init from 1994 up until systemd became the distro default.
  - chris_wot 11y ago
    Odd. Must be a bug, did you report it yourself?
    - cm3 11y ago
      No, I didn't because I didn't want systemd-coredump to handle (and grab) core dumps in the first place and existing discussions and bug reports didn't appear to miss public awareness of the issue. Also previous experience with the maintainers left a bad taste in my mouth. I should be more professional, but the mental barrier to engage with the systemd community is rather high. I cannot say the same about other freedesktop teams with which I regularly communicate in bugzilla.
      - chris_wot 11y ago
        Sorry to hear that.
        cm3 11y ago
        You don't have to be sorry, it's just that systemd as integrated in distros asks for regular QA work by the users, which I don't want to spend my time on. I'm happy to QA certain applications I follow closely, but in the past a Linux system once configured just worked even across major release upgrades. The patch OpenSUSE integrated to work around coredumpd was funny and quite all encompassing, all the while looking like they're trying very hard to close all possible avenues for it to creep back in. It's somewhere linked in an ArchLinux forum thread as a link to an opensuse github commit. Considering OpenSUSE distro devs as informed and capable that commit convinced me that at some point the workaround of overriding kernel.core_pattern in /etc/sysctl.d/50-coredumpd.conf might stop working. I don't look forward to that day and might switch to another distro before that.
        chris_wot 11y ago
        Actually, that's not true. I've had situations where my configurations broke between major releases of Ubuntu. I reported the issue and eventually it got resolved (no idea how I'm afraid), but whatever the issue for me it must have been an edge case as it wasn't widely reported. That seems to be the case for you as well. You have my sympathies, it's most frustrating when it occurs.
makomk 11y ago
Same thing with Lennart's previous project PulseAudio which also has no real stable releases and basically relies on distros to try and take the beta-quality upstream releases and turn them into something that actually works reliably. (My favorite was the PulseAudio release that shipped with a change that was literally incomplete, changing the interal resampling API without changing all the resamplers affected. Crashing ensued. Was rolled back in the next release, but that came with a whole new set of feature patches with the same level of QA applied.) It probably doesn't help that they're both heavily developed by Red Hat, who see taking open source software and turning it into something stable and end-user viable as their secret sauce that justifies paying them lots of money.
- cm3 11y ago
  I've been able to avoid Pulseaudio and therefore didn't experience the issues it had in the past but I've heard that the new maintainers fixed stuff and are doing a better job, though I still don't use it and hence don't have first hand experience. I wouldn't blame Red Hat per se but the GNOME fall back they ship with RHEL is a joke and in no way resembles the old GNOME desktop Pixar was used to.
- forgotpwtomain 11y ago
  It's 2016 and I still have issues with pulseaudio, frankly I was somewhat surprised they let him replace init with systemd - given the terrible mess that pulseaudio has been historically.
  - cm3 11y ago
    And audio professionals working on JACK don't seem to have any interest in pushing it while Lennart has been selling PulseAudio as the low-power alternative to JACK. Maybe he would have been a better fit within Android.
- rwmj 11y ago
  I agree with the rest of your post but I can assure you it's not the policy of Red Hat to release unstable upstream software. I am a Red Hat employee and I'm as annoyed as anyone that systemd doesn't have separate upstream development and stable releases. Also what's with the stupid versioning of systemd/udev? Having a single version number is simply a dumb idea.

by cm3 11y ago

chris_wot 11y ago

Try setting Storage=external in coredump.conf [1] - you seem to have it set to both, which I have to agree is probably less than ideal. 1. https://www.freedesktop.org/software/systemd/man/coredump.conf.html https://www.freedesktop.org/software/systemd/man/coredump.co...

cm3 11y ago
Nope. I've scoured previous bug report and discussions and the only sure way was to prevent systemd from swallowing core dumps. It had the nice side effect that I learned the format string and configured it to my personal needs. But having to reverse engineer in order to remove crashes is not stable software and just a tech preview. If I wanted to be cynical, I'd believe anything coming out of systemd, regardless of quality, is accepted as the new way while discarding existing ways as obsolete. I should add to my startup hangup remark that I never before had a startup problem that was intermittent with plain old stupid init from 1994 up until systemd became the distro default.
- chris_wot 11y ago
  Odd. Must be a bug, did you report it yourself?
  - cm3 11y ago
    No, I didn't because I didn't want systemd-coredump to handle (and grab) core dumps in the first place and existing discussions and bug reports didn't appear to miss public awareness of the issue. Also previous experience with the maintainers left a bad taste in my mouth. I should be more professional, but the mental barrier to engage with the systemd community is rather high. I cannot say the same about other freedesktop teams with which I regularly communicate in bugzilla.
    - chris_wot 11y ago
      Sorry to hear that.
      - cm3 11y ago
        You don't have to be sorry, it's just that systemd as integrated in distros asks for regular QA work by the users, which I don't want to spend my time on. I'm happy to QA certain applications I follow closely, but in the past a Linux system once configured just worked even across major release upgrades. The patch OpenSUSE integrated to work around coredumpd was funny and quite all encompassing, all the while looking like they're trying very hard to close all possible avenues for it to creep back in. It's somewhere linked in an ArchLinux forum thread as a link to an opensuse github commit. Considering OpenSUSE distro devs as informed and capable that commit convinced me that at some point the workaround of overriding kernel.core_pattern in /etc/sysctl.d/50-coredumpd.conf might stop working. I don't look forward to that day and might switch to another distro before that.
        chris_wot 11y ago
        Actually, that's not true. I've had situations where my configurations broke between major releases of Ubuntu. I reported the issue and eventually it got resolved (no idea how I'm afraid), but whatever the issue for me it must have been an edge case as it wasn't widely reported. That seems to be the case for you as well. You have my sympathies, it's most frustrating when it occurs.

makomk 11y ago

Same thing with Lennart's previous project PulseAudio which also has no real stable releases and basically relies on distros to try and take the beta-quality upstream releases and turn them into something that actually works reliably. (My favorite was the PulseAudio release that shipped with a change that was literally incomplete, changing the interal resampling API without changing all the resamplers affected. Crashing ensued. Was rolled back in the next release, but that came with a whole new set of feature patches with the same level of QA applied.) It probably doesn't help that they're both heavily developed by Red Hat, who see taking open source software and turning it into something stable and end-user viable as their secret sauce that justifies paying them lots of money.

cm3 11y ago
I've been able to avoid Pulseaudio and therefore didn't experience the issues it had in the past but I've heard that the new maintainers fixed stuff and are doing a better job, though I still don't use it and hence don't have first hand experience. I wouldn't blame Red Hat per se but the GNOME fall back they ship with RHEL is a joke and in no way resembles the old GNOME desktop Pixar was used to.
forgotpwtomain 11y ago
It's 2016 and I still have issues with pulseaudio, frankly I was somewhat surprised they let him replace init with systemd - given the terrible mess that pulseaudio has been historically.
- cm3 11y ago
  And audio professionals working on JACK don't seem to have any interest in pushing it while Lennart has been selling PulseAudio as the low-power alternative to JACK. Maybe he would have been a better fit within Android.
rwmj 11y ago
I agree with the rest of your post but I can assure you it's not the policy of Red Hat to release unstable upstream software. I am a Red Hat employee and I'm as annoyed as anyone that systemd doesn't have separate upstream development and stable releases. Also what's with the stupid versioning of systemd/udev? Having a single version number is simply a dumb idea.