Is there a non-systemd alternative to systemd-utils udev?

[lars_the_bear]

Hi folks

I've only been looking at this forum for a couple of months, but I've already seen a couple of threads (maybe more) from people who are confused about why they have bits of systemd in their installation, when they thought they weren't using it. Or from people who have used PACKAGE_MASK to eliminate any residual bits of systemd, and ended up with a non-working system because there's no udev.

To be fair, the situation with udev is well-documented. Nevertheless, I suspect that many people come to Gentoo with the express intention of avoiding systemd (although I appreciate that isn't a universal goal). It surprises me that there isn't a workable, non-systemd version of udev. Or, if there is, it's not very prominent.

I found a file under /var/db called "2021-08-24-eudev-retirement.en.txt", which explains why eudev is no longer maintained. It suggests "sys-fs/udev" as the alternative, but sys-fs/udev does not seem to exist. I'm guessing the sys-fs/udev is now systemd-utils, or part of it.

There do seem to be 3rd-party overlays that still have sys-fs/eudev. There's also mdev from Busybox, but I'm not sure how practical it is.

To be clear: it doesn't bother me that there are files and directories in my installation with 'systemd' in the name. Nor am I much concerned that there might be other unused bits of systemd lurking about. I'm more concerned that system-utils udev is part of the sytemd project, and has had ten years of tinkering from the systemd maintainers. The implications of this tinkering are hard (for me) to assess but, on balance, I would prefer not to use it at all.

So: is there really no way to run Gentoo practically, without using software that is part of the systemd effort?

BR, Lars.

[sMueggli]

The short answer: systemd-utils is the non-systemd udev alternative.

It is like in programming. The hard thing is not to programm (create the logic) but naming the things. Whether you are naming a variable "username" or "a9382593" does not change anything to the interpreted or compiled code. For 99% of the code readers the first variant is better and clearer, but for 1% the latter is preferable (for whatever esoteric reason).

[lars_the_bear]

The short answer: systemd-utils is the non-systemd udev alternative.

I don't think that's correct. I looked in the .ebuild and, so far as I can see, the code is taken directly from the systemd github repo. The major contributors to that repo are names that we associate with systemd.

So far as I can see, systemd-utils is part of systemd. A small part, I agree, but a part, nonetheless. This isn't (IIUC) just a matter of naming.

BR, Lars.

[sMueggli]

If you look at the ebuild, you will see

Code: Select all

RDEPEND="${COMMON_DEPEND}
	boot? ( !<sys-boot/systemd-boot-250 )
	ukify? (
		${PYTHON_DEPS}
		$(python_gen_cond_dep "${PEFILE_DEPEND}")
	)
	tmpfiles? ( !<sys-apps/systemd-tmpfiles-250 )
	udev? (
		acct-group/audio
		acct-group/cdrom
		acct-group/dialout
		acct-group/disk
		acct-group/floppy
		acct-group/input
		acct-group/kmem
		acct-group/kvm
		acct-group/lp
		acct-group/render
		acct-group/sgx
		acct-group/tape
		acct-group/tty
		acct-group/usb
		acct-group/video
		!sys-apps/gentoo-systemd-integration
		!sys-apps/hwids[udev]
		!<sys-fs/udev-250
		!sys-fs/eudev
	)
	!sys-apps/systemd
"

So sys-apps/systemd is weak-blocked. On a Gentoo system with systemd you should not be able to install systemd-utils.

As far as I understand it, udev is open source. So what problem do you have if "systemd people" are contributing to an open source project that they are hosting? Do "systemd people" have a wrong understanding of userspace /dev?

[Zucca]

systemd devs have made few of the systemd utilities totally independent from systemd.
udev and tmpfiles are few examples.

I've personally had incompability issues with other udev implementations when I've tested my own udev rules with those, so I've kept using udev from systemd.

Despite of all this, if you're adventurous, you can try mdev for example.

[pa4wdh]

I've also been searching for alternatives to udev. Apart from the association with systemd i also don't like the way you have to configure it and it's network interface renaming.

If you really want to be independent of systemd i think mdev is the closest you van get: https://wiki.gentoo.org/wiki/Mdev
However, it's limitations (especially with it comes to devicemapper) make it unusable for my use cases.

I also just found mdevd, a mdev compatible daemon separate from the busybox project. I haven't looked enough into this to see it that fits my use cases.
https://skarnet.org/software/mdevd/

[lars_the_bear]

As far as I understand it, udev is open source. So what problem do you have if "systemd people" are contributing to an open source project that they are hosting? Do "systemd people" have a wrong understanding of userspace /dev?

I would prefer, if possible, to avoid anything that is associated with systemd in any way. My reasons are my own, and I'm not interested in justifying them -- too much ink has been spilled already. But from the discussions I see on this forum, I'm sure I'm not alone. What I'm really interested in is whether it's reasonably practicable on Gentoo to avoid systemd-utils udev. If it's not, that's disappointing, but not a show-stopper.

BR, Lars.

[Zucca]

However, it's limitations (especially with it comes to devicemapper) make it unusable for my use cases.

With lvm you should be able to create the nodes without udev. I use it inside my initramfs. I'm not sure how well that fares outside of initramfs.

Moved from "Installing Gentoo" to "Gentoo Chat".

[lars_the_bear]

Moved from "Installing Gentoo" to "Gentoo Chat".

This feels like an installation issue to me. But whatever.

BR, Lars.

[Zucca]

This feels like an installation issue to me. But whatever.

BR, Lars.

You are looking for alternatives for a software. At least now this conversation fits better in chat.
EDIT: Well. On a second thought... You're right. My mistake. This topic still belongs to support section, so: moved to "Other Things Gentoo".

If/when you choose another udev implementation for your system, then I'd suggest you to start a new topic with the udev implementation name in the title, so it can reach more those who are familiar with the specific implementation.

But back to the topic: Some people here have also went with static dev. The article is, however, quite old so proceed with caution if you intend so.

[lars_the_bear]

...I'd suggest you to start a new topic with the udev implementation name in the title, so it can reach more those who are familiar with the specific implementation.

Fair point. I'm just not sure there is one. All the alternatives seem to be either old (eudev, static dev) or designed for very minimal set-ups (mdev). I'm just trying to work out what alternatives there might be, if any. I'm not desperately concerned about systemd-utils -- not enough to try to create my own udev, anyway. It would be nice if eudev remained a first-class part of Gentoo (as I presume that elogind is), but I fully understand the difficulties that would raise.

BR, Lars.

[Chiitoo]

All the alternatives seem to be either old (eudev, static dev) or designed for very minimal set-ups (mdev).

I wouldn't say 'static-dev' is old, at least not in the same sense as 'eudev', which is software requiring a lot of maintenance, which it didn't get, and which is why it was removed as the default as well as from the official Gentoo repository.

The method and guide referred to might be a bit old, though, but essentially it just means you're doing things manually.

[lars_the_bear]

The method and guide referred to might be a bit old, though, but essentially it just means you're doing things manually.

Sure. This is what I do on my embedded ARM Linux systems. I don't run udevd at all. But there I have fixed hardware, known in advance. It even works with Xorg, if you're using completely fixed hardware, and don't mind writing X config files, as we did in the old days.

I've not had much luck with this approach on general-purpose desktop systems -- it's just too fiddly if you plug and unplug things all the time. Well, too fiddly to eschew systemd-udevd, which is generally unobjectionable in itself.

I'd be interested in knowing if anybody else is successfully using static configuration on a desktop system.

BR, Lars.

[pa4wdh]

However, it's limitations (especially with it comes to devicemapper) make it unusable for my use cases.

With lvm you should be able to create the nodes without udev. I use it inside my initramfs. I'm not sure how well that fares outside of initramfs.

Maybe i should look into this again, last time was a few years ago. My (server) setup is a combination of mdraid, lvm and dmcrypt stacked together and that was a show-stopper back then.
A simpler use-case is simply dmcrypt on an external HDD for backups, i got the impression that might work nowadays.

[elbci]

I have this trolling medical condition. Once every two or so yrs I go to internet, post a few off-topic rants, see how things got worse in the mean time and go back to my dogs and too-big-for-me-backyard. So... here we go...

I would prefer, if possible, to avoid anything that is associated with systemd in any way. My reasons are my own, and I'm not interested in justifying them -- too much ink has been spilled already.

(my emphasis)

Since retirement I was on debian witch is "next, next, click, click" so I didn't had incentives to understand any bash this, sudo that. I was just fine running Linux and pestering my wife with "look, wobbly windows! / Sure honey, but where is iTunes from before?"... When debian become morally untenable a few yrs back, I made a note to myself and finally few moths back I start looking for a new distro. That's when I found that basically linux is no more, run now by corporations with Embrace Expand Extinguish plans in final stage. The new Ubuntu for (fewer and fewer) young ppl is Kali but not necessarily for ideological reasons, mainly for cool mimetic association with Mr Robot main character. Distrowatch -debian -systemd gives scary few scary options. Fine, after all I don't mind learning new stuff and I will not die playing only vinyls for a few days if I really mess my reFIND, I'm not really in a Bobby Sands or Assange situation. But scarier still was reading a Slackware similar discussion, someone asking if some package (elonging?) was systemd or not. Basically the guy got this answer: "you don't like it - we don't care. Shut up or get banned". Users are completely optional when FOSS is only a CV enhancer for ppl on their way to a corporate job or GoogleTube telesales career. For me, Richard Stallman was irrelevant due to the limited scope of he's 'radicalism', now he's just irrelevant. At the time I was like, never mind privatizing math, they're privatizing jails and war! Then they bombed Belgrade and opened Guantanamo and I just gave up. After all, I had to buy the twice-a-year-new-macbook and the 5cm-longer-than-my-neighbour-car. I'm sorry for that! I'm sorry I listened to Keith Jarrett or Garbareck or Shostakovitch before understanding Cake - Rock'n Roll Lifestyle, I'm sorry I knew who was Andy Warhol before knowing, say, Michael Parenti or Patrice Lumumba. I'm sorry I didn't get banned from here and there more often and much earlier.
So I say, no, not enough ink was spilled! Some youngster might stumble on one of these old ppl forums, find about our mistakes and maybe even avoid some of them...

Oh, and to any developers and maintainers out there that might still believe FOSS can be more that a pass time or a networking opportunity: I'll understand and engage with "we don't have resources to fork KDE or systemd", I'll even settle for i3 or tmux (just put the man pages in F1 or something) but "we can't therefore we pretend we don't care" it's just sad, for everybody.

[logrusx]

I have this trolling medical condition. Once every two or so yrs I go to internet

Could you please go somewhere else next time. Thank you.

[Zucca]

@elbci "nice story bro", but we've had conversations like this before. Let's not derail this topic any more than it needs to be.
Currently we're exploring the possibilities of replacing only systemd-udev.

[lars_the_bear]

It's a shame that it's impossible to discuss any aspect of systemd without provoking a heated response. I'm not a fan of systemd, but I hope I am at least able to discuss it without frothing at the mouth.

My concern about systemd_udevd is that it doesn't really seem to be independent of the rest of systemd. Looking at the source code, I see many calls to bus_connect_system_systemd() which connects to systemd via a socket at /run/systemd/private. I don't know enough about systemd to know whether these operations are, or could be, problematic on a non-systemd system. They all seem to fail gracefully, and clearly systemd_udevd does work right now without systemd.

My worry is that, in the longer term, integration between systemd_udevd and the rest of systemd will become tighter. That integration is already there, even if it's not yet problematic. Whatever else can be said about systemd, I'm fairly sure that modularity of the different components is the maintainers' number one design priority. Sooner or later, systemd_udevd might not work without the rest of systemd.

Then what? I guess what I'll do is fall back on all-manual device management, although it's a pain. I wondered what the few other non-systemd Linux distros do in this area, but all I find is confusion there as well. The lack of a non-systemd udevd seems to be a serious problem for everybody who doesn't want to buy into systemd.

Having said that, I don't have the time to write and maintain one. I fully understand that it's not the job of the Gentoo maintainers to fix this mess, even if they had the resources; but I can't think of anybody else who will :/

BR, Lars.

[GDH-gentoo]

I also just found mdevd, a mdev compatible daemon separate from the busybox project. I haven't looked enough into this to see it that fits my use cases.
https://skarnet.org/software/mdevd/

Well, mdevd is compatible with mdev and configured with an /etc/mdev.conf file, so if its limitations make mdev unusable for your use cases, mdevd will also be unusable...

But scarier still was reading a Slackware similar discussion, someone asking if some package (elonging?) was systemd or not. Basically the guy got this answer: "you don't like it - we don't care. Shut up or get banned".

Link?

It's a shame that it's impossible to discuss any aspect of systemd without provoking a heated response. I'm not a fan of systemd, but I hope I am at least able to discuss it without frothing at the mouth.

There are historical reasons for that, but, in 2024, I simply feel that all there is to say about systemd has already been said.

My concern about systemd_udevd is that it doesn't really seem to be independent of the rest of systemd. Looking at the source code, I see many calls to bus_connect_system_systemd() which connects to systemd via a socket at /run/systemd/private.

In the udev part of the code?

The lack of a non-systemd udevd seems to be a serious problem for everybody who doesn't want to buy into systemd.

Having said that, I don't have the time to write and maintain one.

That's a sentiment shared by many people, and it explains udev's status quo

[logrusx]

It's a shame that it's impossible to discuss any aspect of systemd without provoking a heated response. I'm not a fan of systemd, but I hope I am at least able to discuss it without frothing at the mouth.

I don't see anything heated here, except that self-proclaimed troll post which should be completely ignored. And even that response doesn't seem heated to me. Don't take the fact that others don't agree with your idea of reality for heated response. Also, don't take it personally.

Then what?

Then somebody will do something about it.

Best Regards,
Georgi

[lars_the_bear]

In the udev part of the code?

https://github.com/systemd/systemd/blob ... m-util.c[b][/b], line 25, for example.

There are other references. I honestly don't know whether these code elements are part of the udevd daemon, or just the udevadm command-line utility. Possibly the latter.

In the end, I'm not sure it makes much difference. Unless the systemd guys have made a solemn undertaking to keep systemd_udevd independent of the rest of systemd, I think it has to be regarded as vulnerable. Not every part of systemd is integrated with every other part, but I think the development tendency is in that direction. I'm fairly sure that, if it would make systemd work better as a whole to have udevd more tightly integrated, the maintainers wouldn't hesitate to make that change.

But perhaps I'm being pessimistic. I don't know what conversations there might have been in the past, between the Gentoo folks and the systemd folks. I'd like to hope that, if the systemd maintainers felt it would be beneficial to make udevd a more tightly-integrated part of systemd, they'd realize the impact that would have on some other Linux distributions, and would at least make it swtichable. Unlike the haters and conspiracy theorists, I hold to the view that the systemd maintainers are basically decent people, who care about the future of Linux.

But they do have their agenda, as well all kind-of do.

BR, Lars.

[elbci]

Final notes:

Could you please go somewhere else next time. Thank you.

Inconsequential spam with a whiff of "I own this internet". Pls refrain from further exhibiting your unwaranted superiority simplicity. Thank you.

@Zucca

Currently we're exploring the possibilities of replacing only systemd-udev.

Constructive! Simple, concise, yet hope giving. Thnx!! [Goes off searching for the sticky "How can you help"]


@lars_the_bear
Long as it was my frothing got 50/50 results. One "I have nothing to say" and one usefull and optimist: "We are working on it. Go bring some pizza and shut up".

@GDH-gentoo requested link (with same username, I laughed posting, hope y do reading
https://www.linuxquestions.org/question ... page3.html



Back on topic: the post above is on code faults of udev and I copy below the part of mdev so it doesn't get lost in thread:

I also just found mdevd, a mdev compatible daemon separate from the busybox project. I haven't looked enough into this to see it that fits my use cases.
https://skarnet.org/software/mdevd/

Well, mdevd is compatible with mdev and configured with an /etc/mdev.conf file, so if its limitations make mdev unusable for your use cases, mdevd will also be unusable...

[CaptainBlood]

Maybe off topic...
Using without-systemd overlay here:
No systemd-utils installed.

Thks 4 ur attention, interest & support.

[eschwartz]

In the udev part of the code?

https://github.com/systemd/systemd/blob ... m-util.c[b][/b], line 25, for example.

There are other references. I honestly don't know whether these code elements are part of the udevd daemon, or just the udevadm command-line utility. Possibly the latter.

I looked it up. This file, at least, is one of the source files compiled into /usr/bin/udevadm.

In the end, I'm not sure it makes much difference. Unless the systemd guys have made a solemn undertaking to keep systemd_udevd independent of the rest of systemd, I think it has to be regarded as vulnerable. Not every part of systemd is integrated with every other part, but I think the development tendency is in that direction. I'm fairly sure that, if it would make systemd work better as a whole to have udevd more tightly integrated, the maintainers wouldn't hesitate to make that change.

There is a soft commitment by the systemd developers that as long as you don't mind building the systemd repository, you can install components such as udev without using systemd as your init system.

Will it last? I don't know. But it seems to me that they are more open to this than they were in times past.

But perhaps I'm being pessimistic. I don't know what conversations there might have been in the past, between the Gentoo folks and the systemd folks. I'd like to hope that, if the systemd maintainers felt it would be beneficial to make udevd a more tightly-integrated part of systemd, they'd realize the impact that would have on some other Linux distributions, and would at least make it swtichable. Unlike the haters and conspiracy theorists, I hold to the view that the systemd maintainers are basically decent people, who care about the future of Linux.

Much of the reason that forks of systemd such as eudev failed in the past is because a number of people who would have otherwise worked on them, decided it wasn't worth the time and effort when udev can be built from the systemd repo and used on its own, without using systemd as init.

I strongly suspect that the day systemd makes this impossible will be the day that eudev re-forks the latest version of systemd that was possible to build a standalone udev, and rebases on that. In fact, members of the eudev project are already on record as saying that eudev is badly behind and missing useful functionality, but that it is *not worth* syncing with newer systemd versions, "because the whole thing is a waste of time anyway -- udev can be built and used on its own". Once that is no longer true, the reasons for not bothering to re-sync will no longer be applicable, and eudev will come back to life since it is finally needed again.

[lars_the_bear]

I strongly suspect that the day systemd makes this impossible will be the day that eudev re-forks the latest version of systemd that was possible to build a standalone udev, and rebases on that.

Should that need arise after I have retired (next year, all being well), I'd be happy to help out. I don't want to simply moan about systemd, and then do nothing to support the alternatives.

I just hope that, when/if the day does come, there are enough people left who care, for it to be an effort with undertaking.

BR, Lars