From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 4FE9D158094 for ; Tue, 30 Aug 2022 12:26:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AC8B4E08F3; Tue, 30 Aug 2022 12:26:53 +0000 (UTC) Received: from uriel.iewc.co.za (uriel.iewc.co.za [IPv6:2c0f:f720:0:3::9a49:2248]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8777CE0898 for ; Tue, 30 Aug 2022 12:26:53 +0000 (UTC) Received: from [2c0f:f720:fe0c:3d00::1] (helo=tauri.local.uls.co.za) by uriel.iewc.co.za with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oT0KN-0000Hg-Dg; Tue, 30 Aug 2022 14:26:47 +0200 Received: from [192.168.42.206] by tauri.local.uls.co.za with esmtp (Exim 4.94.2) (envelope-from ) id 1oT0KL-0007Dl-S4; Tue, 30 Aug 2022 14:26:46 +0200 Message-ID: Date: Tue, 30 Aug 2022 14:26:45 +0200 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [gentoo-dev] Last rites: sys-fs/eudev Content-Language: en-GB To: gentoo-dev@lists.gentoo.org, Arve Barsnes References: From: Jaco Kroon Organization: Ultimate Linux Solutions (Pty) Ltd In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-report: Relay access (uriel.iewc.co.za). X-Archives-Salt: 47ba3922-adad-49fb-9b14-41067adb180e X-Archives-Hash: 8eca9225f6a1935743351f71b2fc41e9 Hi Arve, On 2022/08/30 12:27, Arve Barsnes wrote: > On Tue, 30 Aug 2022 at 11:52, Jaco Kroon wrote: >> I note that the default provider for the virtual is systemd-utils[udev], >> followed by sys-fs/udev, sys-fs/eudev and finally sys-apps/systemd. >> This contradicts the wiki page which states that sys-fs/udev is the >> default (https://wiki.gentoo.org/wiki/Udev). >> >> Is there more comprehensive documentation around about this, and which >> should be preferred when? > sys-fs/udev is also just a virtual now, which pulls in > systemd-utils[udev], so using either works exactly the same. Thanks, I missed that.  That does help to clear things up. This leaves three implementations, systemd-utils[udev], eudev and systemd. We don't use systemd so that eliminates that, can I safely assume that systemd-utils[udev] is "extracted" from systemd and really the same thing?  Ie, it's the udevd without the associated systemd environment?  So really only two implementations. eudev then is the wild horse in that it was forked from the days when sys-fs/udev got incorporated into systemd, and have been following a parallel but somewhat independent path?  It doesn't contain many of the newer systemd-udev "features" and "lags behind"? Which, assuming then my understanding is now improved (which I believe it is), then the selection should be based as follows: 1.  If you're using systemd, use the embedded udevd. 2.  If you're using openrc, you should prefer sys-fs/udev aka systemd-utils[udev] unless you have a specific reason to rather use eudev? eudev has served me very well for very long, and avoided a fair number of LVM related deadlock issues we experienced with sys-fs/udev at the time.  We've been moving back, and I'm not convinced those have been eliminated, but I could not yet prove any of the recent system deadlocks we've seen relates to systemd-udev. (The one deadlock we did manage to trap was without a doubt something with the linux kernel IO scheduler, possibly related to raid6, however, lvm is also involved in that path, which does involve udev.  Also the system that most frequently runs into problems - only one with software raid6, but it also by far makes the most aggressive use of lvm snapshots.  Thus no definitive patterns.) Being a creature of habit based on experience I am sceptical.  I am contemplating throwing that one host back to eudev and seeing if that "solves" the problem ... but how long is a piece of string. Thanks for the information, I'll let the above simmer a good long while. Kind Regards, Jaco