openrc

Lone_Wolf · 2019-11-14 15:36:04

NOTE
this thread is about systemd and openrc coexisting on an archlinux installation WITH the base meta-package installed
Those that want a systemd-free system should look elsewhere.

After I had to replace my main rig last year, setting it up to boot with openrc was postponed several times.
I have now setup a VM with a minimal arch install and started working on updating / adapting / extending
the openrc aur package of which i'm co-maintainer.

A few questions :

I plan to create individual packages for services that will use upstream gentoo sources.
A quick tally indicates there will be 20+ services that most people will consider "basic functionality"

For repo packages groups or meta-packages can be used to ease installing.
Would one of those work for AUR packages or are there alternatives ?

Services like udev & dbus are not in the openrc default set.
Should they be started automatically or should that decision be left to the user ?

example PKGBUILD and .install file

# Maintainer: Lone_Wolf <lonewolf at xs4all dot nl>

pkgname=openrc-udev-init-scripts
pkgdesc="udev startup scripts for openrc"
pkgver=33
pkgrel=1
_name='udev-gentoo-scripts'
arch=('any')
depends=(openrc)
url="https://packages.gentoo.org/packages/sys-fs/udev-init-scripts"
license=('GPL')
source=("https://gitweb.gentoo.org/proj/udev-gentoo-scripts.git/snapshot/${_name}-${pkgver}.tar.gz")
md5sums=('6defba6df4c991dbdc121851b9952692')
sha512sums=('2119aace937da02f47a5adc9af720587d25c2852cf70a9bcb04138e3ee511308c8f30cf0301fbec58cf0432b7fd6672ae6a02d1740c774703959197b3511fbcc')
install=$pkgname.install

package() {
    cd ${_name}-${pkgver}
    make SYSCONFDIR="/etc/openrc" DESTDIR="${pkgdir}" install
}

# openrc-udev-init-scripts.install
## arg 1:  the new package version
post_install() {
	rc-update add udev sysinit
	rc-update add udev-trigger sysinit
}

## arg 1:  the old package version
post_remove() {
	rc-update delete udev sysinit
	rc-update delete udev-trigger sysinit
}

Last edited by Lone_Wolf (2019-11-14 20:36:15)

Alad · 2019-11-14 21:52:21

Please don't create 20 PKGBUILDs for 20 services. If you insist on using 1 package per service, use a split package.

Services should not be started automatically at all. Use a post install message.

Lone_Wolf · 2019-11-15 10:51:26

Using 1 package per service increases flexibilty a lot , combining that with not automatically starting services does increase flexibility even more.

I hadn't considered a split package as these services have unrelated sources.
The service files I found sofar don't create any binaries and only require a package() function.
Assuming install= can be used in package_foo() a split package solves several of my issues.

It does introduce a new issue though :
split packages mandatory have the same pkgver & pkgrel ,
The services package would need to have its own version and include info to preserve the link with 'real' upstream versions of sub-packages.

I do think the advantage of a split package is bigger then the disadvantage.

Time to start a list of 'essential' services as well as a draft for a new openrc wiki page.
I've been wanting to do something worthwile with my wiki user page for a long time, this seems like a good opportunity.

Thanks for the response, Alad.

rasat · 2019-11-24 14:30:49

Nice to know this openrc feature is still discussed in Arch, which started in 2012 by artoo.
https://bbs.archlinux.org/viewtopic.php?id=152606

Recently I tested Artix Linux openrc developed by artoo and other members. Works well with Gnome and KDE apps (my favorite combination). Earlier did a test converting Debian systemd to SysV by using Devuan repos, smooth and straightforward. Two days ago tried Arch with AUR elogind and openrc, didn't work. With this link managed with few tweaks, -Rdd and repo link correction.
redacted

I am aware, this is not the topic here, which can be discussed in another tread. I am curious, what's the benefit running systemd and openrc simultaneously?

EDIT: I am asking, this combined feature is one of the nice configs of MX Linux.... using systemd-shim, which allows for systemd and sysVinit to be installed simultaneously.

Mod Note: please do not link to suggestions that users break their systems.

Last edited by HalosGhost (2019-11-25 02:17:15)

rasat · 2019-11-25 19:01:24

In 2014, there was a discussion about systemd-shim.
https://bbs.archlinux.org/viewtopic.php … 7#p1441387

It works in other distros, could be interesting to try again. Maybe convert MX linux's <systemd-shim_10-4_amd64.deb> and <systemd-shim-dbgsym_10-4_amd64.deb> packages to pkg.tar.xz. Just guessing, I don't have the knowledge, but ready to test if anyone will develop required AUR packages.

Last edited by rasat (2019-11-25 21:26:28)

Lone_Wolf · 2019-11-26 13:04:48

I am curious, what's the benefit running systemd and openrc simultaneously?

Having multiple options (in the past i've also booted runit ) helps troubleshooting and exploring new things is fun.
The main benefit for me though is using a modern but simple init system while staying an archlinux user.
You could say I get the best of two worlds this way : archlinux and openrc .

I do remember systemd-shim but never got it to work on archlinux, and replacing / using logind & polkit is low on the list of things that need to be done.

I've started updating https://wiki.archlinux.org/index.php/User:Lone_Wolf with my ideas.

Last edited by Lone_Wolf (2019-11-26 13:05:19)

rasat · 2019-11-27 11:41:57

Lone_Wolf wrote:

You could say I get the best of two worlds this way : archlinux and openrc .
I've started updating https://wiki.archlinux.org/index.php/User:Lone_Wolf with my ideas.

I support, this would be great.
I did an experiment with Artix PKGBUILDs. Managed to get elogind and openrc installed on Arch, which works fine as such. But not stable as long as systemd depended packages are not compiled against elogind or openrc. This what Artix did... lot of work.

As its now, systemd and openrc cannot join into one. As per this thread, some type of "relay" (systemd-openrc) package is needed. If I am not wrong, could a "symlink" generating package do the job? Not that other packages have to be compiled against this "relay", but updates the links after each package upgrade(s).

Last edited by rasat (2019-11-27 12:37:46)

Alad · 2019-11-27 18:58:22

This might work once pacman gets support for alternatives.

https://wiki.archlinux.org/index.php/Us … ternatives

rasat · 2019-11-28 16:28:03

Great, sounds interesting. Any idea when this alternative will be ready. Allan's page was updated quite recently.

Last edited by rasat (2019-11-28 16:29:11)

Alad · 2019-12-02 13:54:54

I have no idea. Between the idea of hooks in pacman and the actual realisation there were something like 1-2 years. So I'd expect somewhere in 2021, maybe.

Addendum: Gnome won't work without systemd or logind, same for KDE. But you can use their respective applications in any other desktop environments that are not tied to systemd.

Last edited by Alad (2019-12-02 13:58:17)

Lone_Wolf · 2019-12-03 12:15:09

Gnome won't work without systemd or logind, same for KDE.

Last time I used gnome was before systemd existed, and If my memory is correct gnome devs point-of-view is the main reason logind/session management became part of systemd. Let's just say I would be very surprised if gnome worked without logind or elogind running .

KDE otoh ran ok 15 months ago when booted with openrc.
Since there was no valid user session, things like mounting devices with dolphin as user or shutting down from menu didn't work.

Basically archlinux polkit is explicitly linked against systemd-logind by this line in the PKGBUILD :

--enable-libsystemd-login=yes

Everything that relies on policies will fail unless logind is running.
To me that's merely a minor annoyance.

rasat · 2019-12-03 12:19:46

I suggest not to reinvent, which takes time, but check what other distros do. Its quit interesting when looking at my grub menu.
http://amurt.ro/download/mx/my-grub-dec19.jpg

Regarding Gnome and KDE, elogind does the job. Gnome is the default DE among my three distros. Same package list & config, and share same /home.

Last edited by rasat (2019-12-03 12:28:31)

Lone_Wolf · 2019-12-03 12:39:46

I suggest not to reinvent, which takes time, but check what other distros do

I do look at distros like gentoo and artix-linux .
Unfortunately other distros seem to focus on running things with one of systemd / openrc installed , not together.
If you know of distros that allow a multi-init setup* , let me know 'cause I know none.
Especially a distro that allows elogind and systemd-logind to coexist would be very helpful.

*
have multiple (two or more) init systems installed and choose one at boot time.

Alad · 2019-12-03 12:51:11

Lone_Wolf wrote:

Everything that relies on policies will fail unless logind is running.

This is false, because you can use groups:

https://wiki.archlinux.org/index.php/Po … ord_prompt

Especially a distro that allows elogind and systemd-logind to coexist would be very helpful.

They cannot coexist by definition - both provide the same dbus interfaces and such forth. elogind only came to light so that GNOME could run on Guix, so that's not unexpected.

Debian makes a bit easier with their alternatives system, making it easy to switch between elogind + something and systemd.

Last edited by Alad (2019-12-03 12:55:52)

Lone_Wolf · 2019-12-03 13:02:54

This is false, because you can use groups:

Last time I tried that (about 2 years ago) it failed.
Polkit documentation indicated that when polkit was built against libsystemd-login group support was disabled.
Thanks for the reminder though, this is something that's definitely worth doublechecking.

both provide the same dbus interfaces and such forth.

That's exactly what I was afraid of, elogind exits the stage.

Alad · 2019-12-03 13:04:55

Worked for me just fine, and I see no indication it has changed. Polkit has little upstream activity at this point.

Though other factors may be at play (wrong javascript syntax, wrong directory, wrong ordering, etc) so try if the groups fail with logind as well.

Last edited by Alad (2019-12-03 13:06:50)

rasat · 2019-12-04 14:02:24

Lone_Wolf wrote:

If you know of distros that allow a multi-init setup* , let me know 'cause I know none.

If you missed, my grub screenshot shows MX Linux with multi-init on /dev/sda3 (systemd and sysVinit).

Systemd:
linux /boot/vmlinuz-4.19.0-6-amd64 root=UUID=14bf12a9-e82a-4aed-a681-e311cc200fbe ro quiet splash init=/lib/systemd/systemd

SysVinit
linux /boot/vmlinuz-4.19.0-6-amd64 root=UUID=14bf12a9-e82a-4aed-a681-e311cc200fbe ro quiet splash

Systemd and sysVinit:
$ dpkg -S /sbin/init
sysvinit-core: /sbin/init

With systemd
$ cat /proc/1/comm
systemd

With sysVinit
$ cat /proc/1/comm
init

Installed packages:
libpam-systemd
libsystemd0
systemd
systemd-shim
sysv-rc
sysv-rc-conf
sysvinit-core
sysvinit-utils

Last edited by rasat (2019-12-04 14:06:02)

Alad · 2019-12-04 15:16:39

The issue with systemd-shim is that was dropped from Debian, and there's noone else maintaining it. Therefore it's not an option for newer systemd versions.

rasat · 2019-12-04 15:58:34

In MX there were lot of discussion about Debian 10 (buster) dropping systemd-shim. It was solved by MX themselves. MX 19 runs with the new systemd-shim in buster.
https://mxlinux.org/blog/about-mx-19-and-systemd/

EDIT... Debian news:
https://distrowatch.com/dwres.php?resou … story=9482

Last edited by rasat (2019-12-04 16:11:20)

Lone_Wolf · 2019-12-05 15:13:16

I did indeed miss the importance of rasat' screenshot, good to know we're not the only ones trying to make init systems coexist.

Does anyone know whether MX Linux has adopted systemd-shim project and will act as upstream for it ?
Are the sources for the MX linux systemd-shim packages published somewhere ?

Head_on_a_Stick · 2019-12-05 19:12:49

Lone_Wolf wrote:

Does anyone know whether MX Linux has adopted systemd-shim project and will act as upstream for it ?
Are the sources for the MX linux systemd-shim packages published somewhere ?

MX has forked the original GitHub page, added a few patches for Debian buster support and now maintain the code here: https://github.com/MX-Linux/systemd-shim

Not sure how active it is though, my PR from October is still unanswered

Note though that MX use a custom version of systemd, which is needed for integration with the shim: https://github.com/knelsonmeister/systemd

Alad wrote:

Gnome won't work without systemd or logind

It works fine in OpenBSD

Alad wrote:

Debian makes a bit easier with their alternatives system, making it easy to switch between elogind + something and systemd.

The init system is not part of Debian's alternatives. Switching to elogind currently removes the graphical desktop in testing...

rasat · 2019-12-05 19:36:51

Lone_Wolf wrote:

Are the sources for the MX linux systemd-shim packages published somewhere ?

I posted your questions in MX forum.... there is the link, and more questions can be asked.
https://forum.mxlinux.org/viewtopic.php?f=6&t=54574

Alad · 2019-12-06 10:34:52

MX has forked the original GitHub page, added a few patches for Debian buster support and now maintain the code here: https://github.com/MX-Linux/systemd-shim
Not sure how active it is though, my PR from October is still unanswered hmm
Note though that MX use a custom version of systemd, which is needed for integration with the shim: https://github.com/knelsonmeister/systemd

I looked at those links, and one is a PR for Travis CI (completely optional), the second a packaging directory which re-adds some patches that were in debian when systemd-shim was. Not a "custom systemd version".

It works fine in OpenBSD

That's because OpenBSD doesn't use gnome, they use some custom patched version (which IIRC works with consolekit).

The init system is not part of Debian's alternatives. Switching to elogind currently removes the graphical desktop in testing...

I have no idea what's that supposed to mean. All it sounds like is that you should file a bug to debian.

Last edited by Alad (2019-12-06 10:40:37)

Head_on_a_Stick · 2019-12-06 15:47:59

Alad wrote:

Not a "custom systemd version".

I was just paraphrasing the information on the MX GitHub page, which uses the word "modified" instead of "custom". Sorry for the inaccuracy.

Alad wrote:

The init system is not part of Debian's alternatives. Switching to elogind currently removes the graphical desktop in testing...
I have no idea what's that supposed to mean.

I was referring to your claim that Debian's alternatives system makes it easier to switch between elogind & systemd-logind. It doesn't because neither systemd-logind or elogind are part of the alternatives system.

Alad wrote:

All it sounds like is that you should file a bug to debian.

The bug is already filed and being discussed by the developers.

rasat · 2019-12-07 18:33:02

Earlier I was asking.... "what's the benefit running systemd and openrc simultaneously?". In MX there an interesting example what coexist does. Not just as a setup of a particular init along with systemd, but users can also change the secondary init at anytime, such as from sysVinit to runit.
https://forum.mxlinux.org/viewtopic.php?f=23&t=54600

Looking forward to have systemd-shim or other coexist setup in Arch Linux.

Arch Linux

#1 2019-11-14 15:36:04

openrc

#2 2019-11-14 21:52:21

Re: openrc

#3 2019-11-15 10:51:26

Re: openrc

#4 2019-11-24 14:30:49

Re: openrc

#5 2019-11-25 19:01:24

Re: openrc

#6 2019-11-26 13:04:48

Re: openrc

#7 2019-11-27 11:41:57

Re: openrc

#8 2019-11-27 18:58:22

Re: openrc

#9 2019-11-28 16:28:03

Re: openrc

#10 2019-12-02 13:54:54

Re: openrc

#11 2019-12-03 12:15:09

Re: openrc

#12 2019-12-03 12:19:46

Re: openrc

#13 2019-12-03 12:39:46

Re: openrc

#14 2019-12-03 12:51:11

Re: openrc

#15 2019-12-03 13:02:54

Re: openrc

#16 2019-12-03 13:04:55

Re: openrc

#17 2019-12-04 14:02:24

Re: openrc

#18 2019-12-04 15:16:39

Re: openrc

#19 2019-12-04 15:58:34

Re: openrc

#20 2019-12-05 15:13:16

Re: openrc

#21 2019-12-05 19:12:49

Re: openrc

#22 2019-12-05 19:36:51

Re: openrc

#23 2019-12-06 10:34:52

Re: openrc

#24 2019-12-06 15:47:59

Re: openrc

#25 2019-12-07 18:33:02

Re: openrc

Board footer