> On 24 Aug 2021, at 11:24, Jaco Kroon <j...@uls.co.za> wrote: > > Hi All, > > We run glibc based systems. No musl. But we don't use systemd. > > As little as a year back we still ran into issues with systemd-udev > variant breaking systems, the fix of course was to nuke it and install > eudev. Are we certain there is nothing (eg, LVM integration was our > biggest problem resulting in really crazy impossible to debug since we > can't log in due to lvn snapshot creation/removal deadlocking with > systemd-udev - no ask me not how, all I can tell you is that eudev never > exhibited this behaviour) will break?
The problem is that this is a bit indirect. blueness could've easily ended up backporting whatever commit causes your issue, if it is indeed udev, because the idea wasn't to be frozen in time anyway; this just kind of happened accidentally because of time commitments. I appreciate this is going to be a huge pain to debug but reporting this upstream is the only proper fix here. > > Whilst I fully appreciate the difficult of all the various e* packages > (elogind, eudev etc ..) and I most certainly do not have the capacity to > maintain, and therefore I'm in full support of the concept of > deprecating eudev, I'm very, very worried about us suddenly being back > into the reboot-a-server-a-week scenario. In the worst case we've lost > some large filesystems almost certainly due to systemd-udev (we've had a > number of filesystem crashes which was recovered with fsck, but after > ditching systemd-udev and moving to eudev about two years back on this > specific host we've had ZERO further problems other than a failed drive > or two, none of which required a hard-reset to get back to a sane state). I don't doubt this happened as I know you're a persistent debugger, although my hope is that whatever issue you hit has been solved, especially given udev is used by Debian/Fedora/RHEL and all the rest of it. But I accept that if this was <= 1 year ago, that argument doesn't hold quite as much water. I suppose it'd be worth looking to see if there were any kernel or LVM2 regressions fixed around that time too. best, sam
signature.asc
Description: Message signed with OpenPGP
