Is it possible to tell OSHI to not even try to load udev on Linux?

[chadlwilson]

The reasons "why" are a bit silly, so I'm not sure I want to lead with that. Suffice it to say that in the environment I am working with attempting to load udev within the JVM I am using will cause the JVM to crash, and it's not easy for me to fix the root cause issue (glibc, musl libc mumble mumble).

I don't actually need/use these udev-provided stats and am really only looking for things such as canonical operating system name and such. It's a bit overkill, but I like the consistency and API that OSHI gives, even though I am using a small subset of its functionality.

Is there a way to tell OSHI or JNA not to even try loading udev ? Hacks/workarounds that would be confined just to the individual JVM and lead to an UnsatisfiedLinkError also accepted :D

oshi/oshi-core/src/main/java/oshi/software/os/linux/LinuxOperatingSystem.java

Lines 82 to 88 in e3ac471

	try {
	@SuppressWarnings("unused")
	Udev lib = Udev.INSTANCE;
	hasUdev = true;
	} catch (UnsatisfiedLinkError e) {
	LOG.warn("Did not find udev library in operating system. Some features may not work.");
	}

[dbwiddis]

Is there a way ...

Aut inveniam viam aut faciam.

I don't think we currently have such a hack, but it's as easy as submitting a PR and having me cut a release.

We have similar "off switches" with our global config / properties file for:

• not bothering with windows performance counters if they're disabled for performance reasons (gamers and speed, etc.)
• not using kstat2 on Solaris which is apparently buggy

Is it just udev or are there also libc issues?

[chadlwilson]

I believe libc isn't a problem probably because the JVM is all running with glibc and will load that consistently. All bets are probably off (in my stupid scenario) for anything other than libc or zlib (since these are the basic headless JVM requirements we ensure are glibc-based)

It's only udev thats an issue that Ive noticed, because it started being pulled in as an apk dependency by something else and I could workaround it by uninstalling udev. We don't actually need it for our use of that one dependency. But udev is pulled in by lots of things, so probably not sustainable for others building child docker images off our Alpine based containers.

More generally it'd be nice to have a way to get basic OS information without eager loading everything native and hardware-ish but Id also get if that wasn't a design goal.

If you're open to a simpler flag I'll have a look around what makes sense to do so consistently with other things and possibly open a PR.

[dbwiddis]

Definitely open to a PR. We already have a HAS_UDEV boolean... jsut throw a conditional around that code to return false if it's disabled in the properties.

[dbwiddis]

Is there a way to tell ... JNA not to even try loading udev

JNA has the ability to have a per-path specification for any given library so in theory you could point it to an empty directory (thus avoiding the real udev) and causing an unsatisfied link error. I think. This question probably belongs on the jna-users mailing list.

[dbwiddis]

Here's the method I'm thinking of. Never tried to actually use it.:

https://github.com/java-native-access/jna/blob/1dd63c81f8538fa614393cedea2f7112088d1972/src/com/sun/jna/NativeLibrary.java#L523

[chadlwilson]

Hmm, I'm guessing if pointed to an empty dir it will just fall back to locating it on the standard system library path it is currently finding it via, but will have a play.

[dbwiddis]

Yeah, seems to just put it in a search path ahead of jna.library.path. You could create an empty DLL there that would load and have no functions in it though!

[chadlwilson]

Broadly speaking, this does work, but it's too smart to attempt to load a zero-byte .so so this doesn't seem so desirable a route.

[dbwiddis]

Well, let's just patch OSHI. :)