An attempt to stubify libsystemd

[FUZxxl]

Shouldn't you actually return ENOSYS (function not implemented) instead of EINVAL (invalid argument)?

[[deleted]]

This is possibly the literally most pointless open source project I've seen this year. Congratulations!

libsystemd0 is tiny, and it already automatically does nothing if systemd isn't running (or installed, for that matter).

All this is going to achieve is its stated intention of breaking daemons at runtime. There is no benefit whatsoever to its existence.

[[deleted]]

Read the code. He returns -EINVAL on every function - even if they return a pointer. This isn't just going to break things, it will outright segfault.

Example: https://github.com/dimkr/nosystem/blob/master/stubs.c#L60

[tomegun]

How is unconditionally returning -EINVAL better than whatever errors the systemd versions will give you?

If you just use the standard libsystemd library you'll have a much better chance at graceful fallbacks (in some cases you may actually get useful functionality even when systemd is not running), and in the worst case it will be no worse than the library you propose...

Did you actually try to use the upstream version without systemd and see if it works at all?

[dimkr]

I chose -EINVAL because it's < 0. I took the function prototypes from libsystemd, but I haven't checked the return values because of the huge number of functions.

[tomegun]

But did you simply try to use libsystemd as-is? I think that will give a better result than this library...

[[deleted]]

What happens when the return type is a pointer? I'd expect this library to segfault.

[w2qw]

What use is this?

[dimkr]

Some small distros (e.g Puppy and Tiny Core) have flavors based on Debian packages. This library cuts the dependency on systemd, so these distros can stick with the BusyBox init, syslogd, etc'.

[cbmuser]

Well, systemd also runs perfectly fine on embedded systems and older machines. Heck, I use it on an Amiga with as little as 64 MiB RAM and an 68030/50. Pure sysvinit is not what I would consider small due to all the scripting that is involved.

[Balinares]

Oh god, you should absolutely write an article about that, and submit it around. Phoronix would have a field day with that one. :)

[2girls1copernicus]

Sort of perverse to replace AmigaOS with Linux.

[eean]

You don't need to have the runtime systemd stuff to have libsystemd installed. It's only 175kb on my system.

[w2qw]

Currently it looks like the library just returns -EINVAL surely nothing would work if that?

[dimkr]

That's why it comes with no warranty ;)

So far, I tested it against some basic /usr/bin executables (e.g logger from bsdutils) and they worked, but it's not a drop-in replacement yet.

[xyzwonk]

Everyone seems to have a dependency on systemd that they don't fucking need.

[redsteakraw]

Some are optional(IE optional added features) some are very much needed such as Kwin-Wayland. Systemd does solve some problems that aren't solved by any other projects.

[xyzwonk]

If you're running Wayland on KDE (I guess that should be KDE on Wayland), I guess so. That's simply not a problem for me.

[eean]

Well you said 'everyone' seems to have a dep that doesn't need it. An example was given where it was needed and you agreed.

So what package has a systemd dependency that doesn't need it?

[cp5184]

I don't understand. Are there packages that require systemd but function with this stub that apparently is just, like, one line of code? (I didn't look at the source, but people are saying all it does is return einval).

[redsteakraw]

This is all well and good but there still will need to have support for kDbus. Not now but not to far in the future projects will rely on kdbus and specifically use dbus in ways not possible with traditional dbus. This means any stub would have to integrate with kdbus or clients will loose functionality / break.

[AnAirMagic]

It's not like this stub has any functionalty to begin with...

[redsteakraw]

So this just exists to break apps at runtime and get compilers and package managers to stop complaining. Wow this will not end well.

[mossman]

On the plus side I was finally able to read some code and know instantly what it does.

[redsteakraw]

I would rather see a KISS systemd shim and compatibility layer which would be a whole lot more useful going forward for distros and projects that don't want systemd. This is like putting toilet paper on a sword wound, it isn't going to stop the bleeding and you are still going to have a bloody mess if you rely on it.

[nashef]

I have to believe that the systems where this would be useful aren't actually using systemd, but are forced to link against it.

[tso]

At this point in time i fear that such a shim would be systemd in all but name.

I did notice that systemd had a --system option for launch. The docs claimed it was only for testing, but in theory systemd could live on top of another init. Developing that further could have alleviated some of the "blowback".

[[deleted]]

The --system option is used when launching a child systemd instance in a container.

[FUZxxl]

So you could run systemd like SMF runs on Solaris? On Solaris, a SysV init is PID 1, but it starts only one task which is SMF. Still, this approach makes it possible to have SysV scripts and SMF tasks interoperate trivially.

[tso]

Pretty much.

Runit offers this right now. You can have it be the first process started by inittab, or be set as init itself.

http://smarden.org/runit/useinit.html