Puppy Linux Discussion Forum

elogind is the standalone systemd-free session and seat manager. It allows to run apps that depend on systemd such as rustdesk, teamviewer without systemd at all. Slackware implements this because they're using sysvinit.

I tried this on Puppy however it always shows "no session" it means it does not create session and seats. Any ideas on how to make elogind work on Puppy?

elogind details
https://wiki.gentoo.org/wiki/Elogind
https://github.com/elogind/elogind

@mistfire :-

Ask peebee. I think Peter may be able to help with this one...

Perhaps THIS might help? Looks like dbus, openrc and pam are all involved, too.

Just my two-penn'orth.....FWIW.

Mike.

You need PAM+libpam-elogind for elogind to work, but Puppy uses busybox login.

dimkr wrote: ↑Thu Nov 17, 2022 8:06 am

You need PAM+libpam-elogind for elogind to work, but Puppy uses busybox login.

Slackware has PAM and installed it however when I swapped busybox login with login binary from util-linux, threw PERMISSION DENIED error message and the Puppy wont login on tty1. Any ideas how to solve this?

AFAIK you'll need to rewrite /etc/shadow, etc' to make Puppy PAM-compatible.

By the way, you will run into issues later on. I got elogind to work perfectly in dpup, but it just doesn't work for applications running as spot. Puppy is the only distro where you have two users "logged on" simultaneously like this. elogind and the idea of environment variables added by a PAM module are incompatible with Puppy's design, on multiple fronts.

Today's woof-CE runs separate "session buses" for root and spot to make most applications that indirectly depend on systemd (via elogind) work fine even when they run as spot. However, some applications touch files under the user's directory in /run and weird stuff happens when root and spot share the same PAM session.

dimkr wrote: ↑Thu Nov 17, 2022 8:49 am

By the way, you will run into issues later on. I got elogind to work perfectly in dpup, but it just doesn't work for applications running as spot. Puppy is the only distro where you have two users "logged on" simultaneously like this. elogind and the idea of environment variables added by a PAM module are incompatible with Puppy's design, on multiple fronts.

Today's woof-CE runs separate "session buses" for root and spot to make most applications that indirectly depend on systemd (via elogind) work fine even when they run as spot. However, some applications touch files under the user's directory in /run and weird stuff happens when root and spot share the same PAM session.

How you managed to run elogind to dpup?

It was long time ago, but not much more than apt install elogindp and rewriting /etc/passwd, etc'. But it doesn't make all applications that truly depend on elogind "just work" (because they refuse to run as root, other systemd dependencies and so on) so I gave up on it shortly later.

@mistfire, In 2020 I posted about an experimental pulseaudio subsystem for Fatdog64-811. It includes a working elogind built on Fatdog for Fatdog. Fatdog uses busybox login, and no PAM. Because my focus was pulseadio I didn't test elogind extensively, but I recall that I was able to connect to pulseadio via the network, which I presume needs logging in hence elogind. Sorry to say I don't remember all the details, but my build is reproducible on Fatdog, if it can help your investigation.

You can find elogind SFS inside folder "pulseaudio depends" of the shared folder link given in this post.

step wrote: ↑Thu Nov 17, 2022 8:27 pm

@mistfire, In 2020 I posted about an experimental pulseaudio subsystem for Fatdog64-811. It includes a working elogind built on Fatdog for Fatdog. Fatdog uses busybox login, and no PAM. Because my focus was pulseadio I didn't test elogind extensively, but I recall that I was able to connect to pulseadio via the network, which I presume needs logging in hence elogind. Sorry to say I don't remember all the details, but my build is reproducible on Fatdog, if it can help your investigation.

You can find elogind SFS inside folder "pulseaudio depends" of the shared folder link given in this post.

I downloaded fatdog but no elogind found

Perhaps possible way might be to use packages from Devuan (as the main purpose of Devuan is to replace systemd with elogind)
elogind libelogind0 libpam-elogind + dependencies (and perhaps eudev and libeudev are needed too)
https://pkgmaster.devuan.org/devuan/poo ... e/elogind/
edit: but didn't test this on Puppy.

@fredx181 I wouldn't recommend that. The Devuan elogind package conflicts with libsystemd (intentionally), so if you force its installation you won't be able to install anything that indirectly depends on libsystemd. For example, you won't be able to install Blueman. Plus, installing elogind without making Puppy PAM-compatible first doesn't do anything really.

@mistfire
It isn't in Fatdog, you need the package step refers to, from here:
https://drive.google.com/drive/folders/ ... vPYN5ACf1D

dimkr wrote: ↑Fri Nov 18, 2022 5:04 pm

@fredx181 I wouldn't recommend that. The Devuan elogind package conflicts with libsystemd (intentionally), so if you force its installation you won't be able to install anything that indirectly depends on libsystemd. For example, you won't be able to install Blueman. Plus, installing elogind without making Puppy PAM-compatible first doesn't do anything really.

In my Devuan live install, all that works fine (installing blueman too). Do you think it's impossible to implement in Puppy ? (the devuan mechanism, somehow the elogind packages "provide" systemd (and/or libsystemd), not that I know how exactly, btw, and it probably won't be easy to figure out).

fredx181 wrote: ↑Fri Nov 18, 2022 7:20 pm

dimkr wrote: ↑Fri Nov 18, 2022 5:04 pm

@fredx181 I wouldn't recommend that. The Devuan elogind package conflicts with libsystemd (intentionally), so if you force its installation you won't be able to install anything that indirectly depends on libsystemd. For example, you won't be able to install Blueman. Plus, installing elogind without making Puppy PAM-compatible first doesn't do anything really.

In my Devuan live install, all that works fine (installing blueman too). Do you think it's impossible to implement in Puppy ? (the devuan mechanism, somehow the elogind packages "provide" systemd (and/or libsystemd), not that I know how exactly, btw, and it probably won't be easy to figure out).

@fredx181 :-

I take it your Devuan Live is like all other "normal" distros......restricted users, yes? If so, that's why it works there, I would guess.

I don't pretend to understand all that Dima's talking about earlier in the thread, but I CAN kinda see that two simultaneous users might well bugger up a running PAM session....even in the mainstream, I guess 'sudo'-ing temporarily as /root somehow transfers PAM authorization for the short duration of a sudo session?

Getting into unknown territory here..! (Normal for everyone else, of course, but almost a decade with ONLY Puppy doesn't prepare you for life's realities, does it?)

Mike.

mikewalsh wrote:

@fredx181 :-

I take it your Devuan Live is like all other "normal" distros......restricted users, yes? If so, that's why it works there, I would guess.

I'm running it being logged in as root, but yes it's a multi-user system, so can run it as unprivileged user too.
Not really a "normal" distro though it's a build made with the mklive script (so a "Dog" alike system).

I have the impression that you think that you cannot be logged in as root on a multi-user system, well on a standard Ubuntu it may be difficult, but on Debian/Devuan it's well supported.

UPDATE: I was successfully run elogind on Puppy. It requires pam and /bin/login with pam support. However there are some problems to be resolved.

* Upon shutdown it was unable to clear display and show messages during shutdown
* Display managers unable to authenticate root account

fredx181 wrote: ↑Sat Nov 19, 2022 11:10 am

on Debian/Devuan it's well supported.

It will work fine as long as you use systemd or sysvinit+elogind+dbus-x11 (= user has a session bus), and use login from passwd (so user has a PAM session started by libpam-systemd/elogind), but you'll need some hacks to get applications running as spot to integrate nicely.

Most Puppy releases don't have a session bus, don't have the tricks needed to make root and spot use the same services (i.e. talk to the same instance of pipewire, although each user has a different session bus) and use busybox login. A Puppy built today will mostly behave fine even when an application that uses the session bus insists on running as spot, but elogind can't work like this because root and spot use different XDG_RUNTIME_DIR values, spot can't read files in root's XDG_RUNTIME_DIR, environment variables set by PAM modules are not inherited properly, some elogind features (inhibitors) are based on file descriptor passing, and so on.

I don't see how this attempt to run elogind in Puppy without switching away from busybox init and login or adding PAM support to Puppy can succeed, especially if you aim at compatibility with Ubuntu (which is systemd-only at this point) and Slackware. Maybe you can pull this off by forcing login as spot (without closing the PAM session), then steal the environment variables set by login plus inherited file descriptors and pass them to all children of root's login, so both root and spot use spot's PAM session. If I understand correctly, the result would be a Puppy that starts slower (PAM will slow down login) and eats more RAM because there's an extra daemon running ... it's still a single user/single seat distro, but one with working elogind

mistfire wrote: ↑Sun Aug 20, 2023 12:30 pm

UPDATE: I was successfully run elogind on Puppy. It requires pam and /bin/login with pam support. However there are some problems to be resolved.

* Upon shutdown it was unable to clear display and show messages during shutdown
* Display managers unable to authenticate root account

UPDATE: I fixed errors in my statement

elogind told that the current tty was /dev/tty1 but unable to display message and perform interaction during shutdown. Even /dev/pts and /dev/console does not work. I wonder why