Talk:Elogind

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 08:02, 12 January 2025 (UTC)
:: Your reply ~~~~

Navigate to first

Open discussion
Good first discussion
Discussion needing discussion
Discussion needing help
Solved discussion

Suggestion about Suspend to hibernate with elogind

Talk status

This discussion is still ongoing.

When laptop is suspended to ram, it uses very little power, so when the battery runes out user is forced to fully boot up the machine.

There are two ways to prevent this situation: Hibernate with hybrid-sleep, or use loginctl suspend command with the real-time wake timer hook to allow system to wake up and perform hibernate to disk with loginctl hibernate.

Solution is similar to Sabayon's wiki https://wiki.sabayon.org/index.php?title=Auto_hibernate_after_suspend, but it fully uses loginctl command so sys-power/pm-utils becomes obsolete.

First You have to create folder /lib/elogind/system-sleep/ for sleep hooks, and/or /lib/elogind/system-shutdown/ for shutdown hooks.

Then, in /lib/elogind/system-sleep/ place script:

#!/bin/bash
# Script name: /lib/elogind/system-sleep/autohibernate.sh
# Purpose: Auto hibernates after a period of sleep
# Edit the "autohibernate" variable below to set the number of seconds to sleep.

curtime=$(date +%s)

# 60 Minutes should be fine
autohibernate=3600

echo "$curtime $1" >>/tmp/autohibernate.log


if [ "$1" = "pre" ]
then
        if [ "$2" = "suspend" ]
        then
                # Suspending.  Record current time, and set a wake up timer.
                echo "$curtime" >/var/run/rtchibernate.lock
                rtcwake -m no -s $autohibernate
        fi
fi

if [ "$1" = "post" ]
then

        if [ "$2" = "suspend" ]
        then
                # Coming out of sleep
                sustime=$(cat /var/run/rtchibernate.lock)
                rm /var/run/rtchibernate.lock

                # Did we wake up due to the rtc timer above?
                if [ $(($curtime - $sustime)) -ge $autohibernate ]
                then
                        # Then hibernate
                        /bin/loginctl hibernate
                else
                        # Otherwise cancel the rtc timer and wake up normally.
                        rtcwake -m no -s 1
                fi
        fi
fi

You need to add executable permission with: chmod +x /lib/elogind/system-sleep/autohibernate.sh and reboot machine. — The preceding unsigned comment was added by PrSo (talk • contribs) 18th October, 2017

Reviewing the exit menu of fvwm-crystal, I saw it is a much simpler solution to use hybrid-sleep with the lid switch:

FILE /etc/elogind/logind.conf

HandleLidSwitch=hybrid-sleep
HandleLidSwitchExternalPower=hybrid-sleep

If the default <suspend> is not changed to <ignore>, and the desktop or a script issue a loginctl hybrid-sleep sleep command, the script inside fvwm-crystal seam to work, but as I don't know elogind's internal and the fact that, past a given system complexity, the only certainty is the uncertainty, I have no real clue about what we be enforced and if that will be consistent between runs.

If You want it to be handled by the dm/desktop or a script, you can set:

FILE /etc/elogind/logind.conf

HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore

But maybe some desktops will use that setting to know what to do... I make extensive testing of fvwm-crystal, but for the other ones, I let that to their respective developers. --DominiqueMichel (talk) 14:08, 1 November 2024 (UTC)

--DominiqueMichel (talk) 12:30, 1 November 2024 (UTC)

After some thinking, most if not all such desktop will depend on systemd, which imply it must not be a big deal with elogind and is out of the scope of that article. I also think that the users must be aware of these 2 settings and a word about them must therefore be added into the article. --DominiqueMichel (talk) 14:08, 1 November 2024 (UTC)

Also, I saw that hybrid-sleep seam to work as follow, which can be confusing at first:

) It do a resume.
) It do an hibernate during which, on my laptop and that's the confusing part, it re-illuminate the screen with the desktop as it was when hybrid-sleep was launched.
) It go back to its resume state.

Which imply that, when I re-open the screen, the resume go normally very fast. And when a power outrage happened, it make a full reboot from the hibernation image.

--DominiqueMichel (talk) 12:30, 1 November 2024 (UTC)

Kernel configuration needs updating

Talk status

This discussion is done as of 2018-01-22.

I can't find "[*] Simplified Mandatory Access Control Kernel Support" on my kernel 4.13.5 configuration.

Maybe it could be worth also specifying the actual CONFIG_* -variables too? Then tell to enable them using provided script (inside scripts -directory inside the kernel source directory). After applying the changes then users would need to run "make oldconfig". --Zucca (talk) 17:58, 24 October 2017 (UTC)

Sure. Can you update the article? The kernel configuration option is CONFIG_SECURITY_SMACK. Cateee is a wonderful site. Kind regards, --Maffblaster (talk) 19:03, 26 October 2017 (UTC)

Likely addressed by this edit: "Enable different security models" (CONFIG_SECURITY) must be enabled to make the option visible. The contents of the {{KernelBox}} template are correct at least for the 4.14-series, so marking as done. — GuillermoDH (talk) 18:53, 8 December 2018 (UTC)

Please describe life without elogind (USE=-elogind)

Talk status

This discussion is still ongoing.

As I understand we need this for some desktop environments (for example XFCE) when do not want systemd, also for reboot/poweroff without root and mounting without root. Right now I am trying USE=-elogind:

root #emerge --update --deep --with-bdeps=y --newuse --ask @world

[ebuild   R    ] sys-process/procps-3.3.15-r1  USE="-elogind*" 
[ebuild   R    ] gui-apps/swayidle-1.6  USE="-elogind*" 
[ebuild   R    ] sys-apps/dbus-1.12.16  USE="-elogind*" 
[ebuild   R    ] x11-base/xorg-server-1.20.7  USE="-elogind*" 
[ebuild   R    ] gui-libs/wlroots-0.10.0  USE="-elogind*" 
[ebuild   R    ] gui-wm/sway-1.4  USE="-elogind*" 
[ebuild   R    ] sys-auth/pambase-20190402  USE="-elogind*"

Vitaly-zdanevich (talk) 02:24, 17 April 2020 (UTC)

The core problem is that some packages hard-depend on Microsoft SystemD (as I call it, because let’s be real about what sphere it comes from).

So you have four choices:

Be used by the SystemD,
drop in a shim that offers what those packages expect to be there (elogind, etc),
patch the need for it out of those packages (using /etc/portage/patches/… to modify kwin, for example),
or not use those packages at all.

…

Given that logind serves a “problem” that does not actually exist (managing users based on “seats” instead of terminals as if we were still in the mainframe era), the patches are the most correct but hardest solution. Which is why nobody did that (AFAIK)¹.

But usually, the packages hard-depending on something toxic like SystemD are considered toxic themselves, and will treat you just a badly as the packages they depend on. It’s a culture thing. So one just loses one’s hair by going down their route.

Ergo the choice for me is to just not live with the bling bling of massive monstrosities like KDE or Gnome, and at first notice that there is not really anything missing by using the normal non-desktopy non-coproratty tools, and then you notice that you started to adapt things to your way and everything is now fully automated to fit you much better than those shiny packages ever did.

It’s analogous to how I have much less hassle since I replaced networkmanager with just pure netifrc, wpa_supplicant, hostapd, and a few of my own small scripts that essentially only encode MY choices. It’s easily debuggable too! Not obscure and intentionally hard to control.

I am writing my own shell and user space now anyway, so for me, elogind & SystemD it will soon be “legacy software”. As it always was, given that Plan 9 was already a thing, where the core design already made such problems absurd. :)

— Evi1m4chine (talk) 23:32, 21 October 2024 (UTC)

¹ It’s not that hard. Creating a patch describes the procedure well. I often use it to make quick edits to packages.

startx integration not need when sys-apps/dbus is installed

Talk status

This discussion is still ongoing.

sys-apps/dbus-1.12 installs the file /etc/X11/xinit/xinitrc.d/80-dbus which already seems to contain the dbuslaunch command:

#!/bin/bash

# launches a session dbus instance

dbuslaunch="`which dbus-launch 2>/dev/null`"
if [ -n "$dbuslaunch" ] && [ -x "$dbuslaunch" ] && [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
  if [ -n "$command" ]; then
    command="$dbuslaunch --exit-with-session $command"
  else
    eval `$dbuslaunch --sh-syntax --exit-with-session`
  fi
fi

--EoD (talk) (2020-06-28)

This file only gets called (via /etc/X11/xinit/xinitrc) if the user doesn't have an .xinitrc file, or has XINITRC set to /etc/X11/xinit/xinitrc. From the startx(1) man page:

To determine the client to run, startx first checks the environment variable XINITRC for a filename. If that variable is unset, or does not contain a filename, it looks for a file called .xinitrc in the user's home directory. If that is not found, it uses the file xinitrc in the xinit library directory.

-- Flexibeast (talk) 06:51, 29 May 2023 (UTC)