Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is libelogind0 abi compatible with libsystemd0? #97

Closed
Centuriondan opened this Issue Nov 20, 2018 · 47 comments

Comments

Projects
None yet
7 participants
@Centuriondan
Copy link

Centuriondan commented Nov 20, 2018

Hi,

We're using elogind in Devuan and it works well. I was wondering if libelogind0 is an abi compatible replacement for libsystemd0 to the extent we could symlink it as libsystemd0 and applications would be happy to use it?

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Nov 21, 2018

Hi Centuriondan,

unfortunately I have never tried that.

We're using elogind in Devuan and it works well.

I am happy to hear that!

I was wondering if libelogind0 is an abi compatible replacement for
libsystemd0 to the extent we could symlink it as libsystemd0 and
applications would be happy to use it?

Well, the API is reduced, as there are a few functions that make no sense with elogind, like everything that has to do with journald, or syetemd units. Apart from that, no data structures, alignements, calling conventions, parameters or return types have been changed. So this may be possible.

I have never tried that.

If you have both installed, maybe a look at them using something like
https://lvc.github.io/abi-compliance-checker/
could help shed some light on this?

On the other hand, it is generally an XOR decision:
Build everything that needs/supports it either against ConsoleKit2 XOR elogind XOR systemd[-logind].

What I can guarantee is, that if you link something against libsystemd, and then use elogind, that "something" will not work, as the inner workings of libsystemd are quite different. So keeping libsystemd around is no option. But if libsystemd is gone and simply replaced by libelogind, it might work.

I hope I could help you at least a little bit.

@Centuriondan

This comment has been minimized.

Copy link
Author

Centuriondan commented Nov 21, 2018

Hi Centuriondan,

unfortunately I have never tried that.

We're using elogind in Devuan and it works well.

I am happy to hear that!

I was wondering if libelogind0 is an abi compatible replacement for
libsystemd0 to the extent we could symlink it as libsystemd0 and
applications would be happy to use it?

Well, the API is reduced, as there are a few functions that make no sense with elogind, like everything that has to do with journald, or syetemd units. Apart from that, no data structures, alignements, calling conventions, parameters or return types have been changed. So this may be possible.

Ok. As long as the data structures, alignments and callling conventions, parameters or return types haven't been changed, then even if the functions that don't make sense without systemd return a suitably benign or informative error response, it shouldn't be an issue for us.

I have never tried that.

I guess we'll have to give it a whirl then. :-)

If you have both installed, maybe a look at them using something like
https://lvc.github.io/abi-compliance-checker/
could help shed some light on this?

Will do.

On the other hand, it is generally an XOR decision:
Build everything that needs/supports it either against ConsoleKit2 XOR elogind XOR systemd[-logind].

If it is ABI compatible, then we'd enforce XOR at the package level to libsystemd0 and patch our build to only allow one or the other. Consolekit2 is a different issue, and we already have patched our policykit1 package to build support for both elogind as well as consolekit and those support packages are already XOR'd so they can't be co-installed at the same time.

What I can guarantee is, that if you link something against libsystemd, and then use elogind, that "something" will not work, as the inner workings of libsystemd are quite different. So keeping libsystemd around is no option. But if libsystemd is gone and simply replaced by libelogind, it might work.

The idea is to replace libsystemd0 completely with libelogind in Devuan - as libsystemd0 doens't really do anything for us except solve dependency issues on some packages. It saves us having to rebuild quite a number of packages

I hope I could help you at least a little bit.

Yes, very useful.

Thank you!

@kilobyte

This comment has been minimized.

Copy link

kilobyte commented Nov 21, 2018

It'd also avoid the XOR in Debian at all — there's no ConsoleKit at all, thus if libelogind0 could be a drop-in replacement, there's no need for alternatives.

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Nov 21, 2018

It'd also avoid the XOR in Debian at all — there's no ConsoleKit at all, thus if libelogind0 could be a drop-in replacement, there's no need for alternatives.

That's correct for Debian, but Devuan still offers ConsoleKit2, doesn't it?

@kilobyte

This comment has been minimized.

Copy link

kilobyte commented Nov 21, 2018

I see ConsoleKit1 not 2 in Devuan Ceres.

As far as I understand, they had to keep it as elogind didn't work with some desktop environments, but AFAIK all such issues had been already fixed. Thus, I quite fail to see what's the point of keeping that alternative — if elogind works everywhere (it has to, because Debian), there's no benefit in keeping ConsoleKit in Devuan either.

@Centuriondan

This comment has been minimized.

Copy link
Author

Centuriondan commented Nov 21, 2018

@kilobyte It's consolekit2 (v1.2.1) but the binary package names are wrong... I'll fix it next build (and add the appropriate provides.

@Centuriondan

This comment has been minimized.

Copy link
Author

Centuriondan commented Nov 21, 2018

The reason for keeping it is as an alternative as xfce4 still works with consolekit, and there may be others as well - slim login manager depends on consolekit for exanple.

And besides, we don't want to be painted into a corner :-P

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Nov 26, 2018

@Centuriondan : What is the outcome of your experiments? Does it work?

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Feb 16, 2019

@Centuriondan : If there is anything I can do, please reopen. 😉

@Yamakuzure Yamakuzure closed this Feb 16, 2019

@udeved

This comment has been minimized.

Copy link

udeved commented Feb 16, 2019

@Yamakuzure

I can quickly tell my experience.
Any package built by arch against libsystemd works on artix with libelogind as well, granted the package has no systemd journal activated.
For example, a plasma built against libsystemd/systemd works flawlessly with elogind, kde session finds the logind interface and power management also works.

@Centuriondan

This comment has been minimized.

Copy link
Author

Centuriondan commented Feb 16, 2019

It seems libelogind0 works just fine in Devuan as a replacement for libsystemd0

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Feb 19, 2019

@udeved @Centuriondan
I am very happy to hear that!

Thank you both very very much for the feedback! 👍

@Centuriondan

This comment has been minimized.

Copy link
Author

Centuriondan commented Feb 24, 2019

@Yamakuzure Seems I spoke too soon. Turns out that you've dropped some of the abi symbols compared to systemd. Is there a chance you could provide all the api/abi symbols with the unused bits stubbed out as a NO_OP? I ran abi-compliance-checker today - here is the report. (Ignore the added symbols)

compat_report-systemd17-elogind19.pdf

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Feb 24, 2019

@Centuriondan

This comment has been minimized.

Copy link
Author

Centuriondan commented Feb 24, 2019

For Devuan to be able to use libelogind as a complete replacement of libsystemd, then I'd have to say yes, we probably need them all.

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Feb 27, 2019

@Centuriondan : How did you create that report? It has some incorrect details in it, which I blame on the versions compared. (It says I've added two symbols, which I haven't.)

elogind-master has to be compared to systemd-v241, for instance.

Generating an exact report would be enormously helpful!

@Centuriondan

This comment has been minimized.

Copy link
Author

Centuriondan commented Feb 27, 2019

I did say to ignore the added symbols ;-)

I was using abi-compliance-checker to do the comparison - mostly to just see if I could get a useful report.

I was comparing the versions of libsytemd0 v237 to libelogind v241 as you suspect - simply because that's what I had available in devuan ascii as packages.

It's the missing symbols that are the issue to us. Newly added ones won't pose a problem until binaries start using them. I'll see if unstable has matching versions of libsystemd0 and libelogind0 and try running that report again.

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Feb 27, 2019

Hmmm... seems harmless... But we have to stub the whole journald stuff. I won't ship sd-journal.h though, or people might think elogind would add/use/understand systemd-journald all of a sudden.

@Yamakuzure Yamakuzure reopened this Feb 27, 2019

Yamakuzure added a commit that referenced this issue Feb 27, 2019

Prep 241.1: Re-add sd_is_mq(), but make it a stub
Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Feb 27, 2019

Prep 241.1: Re-add sd_bus_creds_get_unit() and sd_bus_creds_get_user_…
…unit() as stubs

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>
@markhindley

This comment has been minimized.

Copy link
Contributor

markhindley commented Feb 27, 2019

Sven,

This might be useful for Debian as well and Devuan.

As for the journald stubs, how about using syslog(2) calls so that any message don't just get lost?

Mark

@Centuriondan

This comment has been minimized.

Copy link
Author

Centuriondan commented Feb 27, 2019

As for the journald stubs, how about using syslog(2) calls so that any message don't just get lost?
I'm in 2 minds about this. It's likely that if systemd-journald isn't running that programs will fall back to using syslog and this is probably preferable, and the right thing to do. I guess the problem is that libsystemd0 ABI will increasingly become a one stop interface for all daemons providing session management, service management, logging etc, and I'm not sure if we should encourage that.

That said, having read the sd-journal api man-pages It would be fairly trivial to map all the inputs to the syslog(3) api.

@Centuriondan

This comment has been minimized.

Copy link
Author

Centuriondan commented Feb 27, 2019

@Yamakuzure

Thanks for the quick turn around on this. ;-)

Yamakuzure added a commit that referenced this issue Feb 28, 2019

Prep 241.1: Add non-functional stubs for all sd_journal API functions
Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>
@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Feb 28, 2019

@markhindley @Centuriondan
syslog seems to be a good idea and the way to go.

However, could you somehow check current master? All missing symbols should at least be there, now.

I'll look into syslog api tomorrow.

@Yamakuzure Yamakuzure self-assigned this Mar 1, 2019

Yamakuzure added a commit that referenced this issue Mar 8, 2019

Prep 241.1: Fix sd-journal.h API functions return values where -ENOSY…
…S is not needed according to their documentations. [Issue: #97]

Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 8, 2019

Prep 241.1: Add missing documentation for the sd-journal.h API.
Most of these functions do nothing as no access to systemd-journal
exists. Some return regular "nothing-to-do"-values, or the normal
error codes when nothing can be done. All other non-working functions
return -ENOSYS.

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 8, 2019

Prep 241.1: Add missing documentation for the sd-journal.h API.
Most of these functions do nothing as no access to systemd-journal
exists. Some return regular "nothing-to-do"-values, or the normal
error codes when nothing can be done. All other non-working functions
return -ENOSYS.

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>
@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Mar 8, 2019

@djlucas The only issues I see is that there have been incidents with users getting elogind as a dependency while being on a systemd-powered system.
That is of course caused by faulty dependency and blocker definitions in the PM system.

Generally speaking I like packages to be aware of elogind within their built systems. systemd and elogind are basically mutually exclusive. Strictly speaking elogind should be usable on a systemd-powered system with disabled systemd-login, but who would actually want that? Makes no sense to me.
Once a package is built, pkg-config is of no relevance any more. So if we go further in the drop-in replacement line of thought, a user could switch between a systemd-powered and non-systemd system without having to reinstall a whole bunch of packages.

@Centuriondan @markhindley I just added the whole API documentation and have changed the stub functions behavior a bit. (see referenced commits above)
Could you please have a swift look whether this looks okay to you?

According to ninja -C build check-api-docs there is still some documentation missing. Some of it doesn't exist within systemd itself, like the whole sd_hwdb_*() documentation.
However, I'd like to get the next releases out this week-end or at the beginning of the next week, so I would postpone adding those (never-missed-before-anyway) man pages for the next service releases, if everybody is okay with it.

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Mar 8, 2019

Quote myself:

I do not know why they use the bare function instead of sd_journal_send_with_location(), but maybe I'll check for location variables and reroute internally somewhere in the future...

Or now. We do it now. 😁

@markhindley

This comment has been minimized.

Copy link
Contributor

markhindley commented Mar 10, 2019

Yamakuzure added a commit that referenced this issue Mar 10, 2019

Prep 241.1: Re-add sd_is_mq(), but make it a stub
Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 10, 2019

Prep 241.1: Re-add sd_bus_creds_get_unit() and sd_bus_creds_get_user_…
…unit() as stubs

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 10, 2019

Prep 241.1: Add sd-journal.h support and minimal functionality
Logging (sd_journal_print*() and sd_journal_send*()) reroute to
syslog.
Functions where it makes sense return their normal value that
indicates non-functionality or error due to journald being missing.
Everything else returns -ENOSYS.

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 10, 2019

Prep 241.1: Add stubs for the hwdb functions in libsystemd.
Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 10, 2019

Prep 241.1: Add missing documentation for the sd-journal.h API.
Most of these functions do nothing as no access to systemd-journal
exists. Some return regular "nothing-to-do"-values, or the normal
error codes when nothing can be done. All other non-working functions
return -ENOSYS.

Other changes in this commit:
 * Add missing d_bus_get_n_queued_*() documentation
 * Mask irrelevant details in man/elogind.syntax.xml
 * Unmask stubbed functions in man/sd_bus_creds_get_pid.xml but make
   clear they are stubs.
 * Make clear why sd_is_mq() is a stub in man/sd_is_fifo.xml

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>
@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Mar 10, 2019

I close this in naive expectation that we finally nailed it with the v241 release. 😉 👍

@Yamakuzure Yamakuzure closed this Mar 10, 2019

@joakim-tjernlund

This comment has been minimized.

Copy link

joakim-tjernlund commented Mar 11, 2019

@Yamakuzure , did you tag the 241 release rigth? Seems like master is 23 commits ahead of this release

@Yamakuzure

This comment has been minimized.

Copy link
Collaborator

Yamakuzure commented Mar 11, 2019

@joakim-tjernlund

This comment has been minimized.

Copy link

joakim-tjernlund commented Mar 11, 2019

OK, but those cherrypicks are very confusing when looking at githubs release page.

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Re-add sd_is_mq(), but make it a stub
Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Re-add sd_bus_creds_get_unit() and sd_bus_creds_get_user_…
…unit() as stubs

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Add non-functional stubs for all sd_journal API functions
Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Add sd-journal.h support and minimal functionality
Logging (sd_journal_print*() and sd_journal_send*()) reroute to
syslog. Everything else returns -ENOSYS.

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Support location variables in sd_journal_sendv() [Issue #97]
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Fix sd-journal.h API functions return values where -ENOSY…
…S is not needed according to their documentations. [Issue: #97]

Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Add missing documentation for the sd-journal.h API.
Most of these functions do nothing as no access to systemd-journal
exists. Some return regular "nothing-to-do"-values, or the normal
error codes when nothing can be done. All other non-working functions
return -ENOSYS.

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Re-add sd_is_mq(), but make it a stub
Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Re-add sd_bus_creds_get_unit() and sd_bus_creds_get_user_…
…unit() as stubs

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Add non-functional stubs for all sd_journal API functions
Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Add sd-journal.h support and minimal functionality
Logging (sd_journal_print*() and sd_journal_send*()) reroute to
syslog. Everything else returns -ENOSYS.

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Support location variables in sd_journal_sendv() [Issue #97]
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Fix sd-journal.h API functions return values where -ENOSY…
…S is not needed according to their documentations. [Issue: #97]

Signed-off-by: Sven Eden <sven.eden@prydeworx.com>

Yamakuzure added a commit that referenced this issue Mar 20, 2019

Prep 241.1: Add missing documentation for the sd-journal.h API.
Most of these functions do nothing as no access to systemd-journal
exists. Some return regular "nothing-to-do"-values, or the normal
error codes when nothing can be done. All other non-working functions
return -ENOSYS.

Bug: #97
Signed-off-by: Sven Eden <sven.eden@prydeworx.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.