Solved ! Hyprland - dbus-update-activation - Zombie process

[CooSee]

merry Xmas @all

has anyone noticed zombie process, e.g. dbus-update-activation - running Openrc system:

the following is from hyperlog:

Code: Select all

[LOG] Executing dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP HYPRLAND_INSTANCE_SIGNATURE QT_QPA_PLATFORMTHEME
[LOG] Process Created with pid 2728

ps -ef | grep defunct

Code: Select all

myusername   2705  2656  0 22:38 ?        00:00:00 [dbus-update-act] <defunct>
myusername   9638  4584  0 23:02 pts/1    00:00:00 grep --colour=auto defunct

and all of a sudden i get some errors regarding notification daemon - i thought this is maybe a dunst issue - therefore i switched to mako and then to swaync, but

somehow first attempts to start it via login fails - but starting swaync manually works.

Code: Select all

[   65.186711] notification-da[2937]: segfault at 3 ip 0000000000000003 sp 00007ffeaaae9968 error 14 in notification-daemon[6115f7d88000+7000] likely on CPU 4 (core 0, socket 0)
[   65.186721] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[   65.344194] notification-da[2946]: segfault at 3 ip 0000000000000003 sp 00007ffead7bcfc8 error 14 in notification-daemon[59396277f000+7000] likely on CPU 4 (core 0, socket 0)
[   65.344204] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[   65.492942] notification-da[2966]: segfault at 3 ip 0000000000000003 sp 00007ffefb54a068 error 14 in notification-daemon[594805948000+7000] likely on CPU 6 (core 2, socket 0)
[   65.492952] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[   65.641501] notification-da[2974]: segfault at 3 ip 0000000000000003 sp 00007ffc717cb928 error 14 in notification-daemon[5ae1879c1000+7000] likely on CPU 4 (core 0, socket 0)
[   65.641511] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[   66.570144] notification-da[2994]: segfault at 3 ip 0000000000000003 sp 00007fff5194d888 error 14 in notification-daemon[5cb28307d000+7000] likely on CPU 0 (core 0, socket 0)
[   66.570154] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[   66.721531] notification-da[3014]: segfault at 3 ip 0000000000000003 sp 00007ffdf92bd808 error 14 in notification-daemon[5c90c4633000+7000] likely on CPU 2 (core 2, socket 0)
[   66.721542] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[   66.867769] notification-da[3021]: segfault at 3 ip 0000000000000003 sp 00007fff380e5428 error 14 in notification-daemon[56b81a280000+7000] likely on CPU 4 (core 0, socket 0)
[   66.867779] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[   77.159927] notification-da[3142]: segfault at 3 ip 0000000000000003 sp 00007ffcff13efa8 error 14 in notification-daemon[5eaa70ee4000+7000] likely on CPU 1 (core 1, socket 0)
[   77.159936] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[  581.212421] notification-da[12497]: segfault at 3 ip 0000000000000003 sp 00007ffdd2afa308 error 14 in notification-daemon[5a26f0516000+7000] likely on CPU 7 (core 3, socket 0)
[  581.212436] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[  767.549875] notification-da[14053]: segfault at 3 ip 0000000000000003 sp 00007ffcf169d808 error 14 in notification-daemon[59ccca3b5000+7000] likely on CPU 2 (core 2, socket 0)
[  767.549913] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[  767.710084] notification-da[14064]: segfault at 3 ip 0000000000000003 sp 00007fff6b2c7748 error 14 in notification-daemon[5f858672e000+7000] likely on CPU 6 (core 2, socket 0)
[  767.710095] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[  767.870435] notification-da[14071]: segfault at 3 ip 0000000000000003 sp 00007fff6e40bbe8 error 14 in notification-daemon[5f86d1c8b000+7000] likely on CPU 7 (core 3, socket 0)
[  767.870445] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[  768.523458] notification-da[14089]: segfault at 3 ip 0000000000000003 sp 00007ffe231bcb08 error 14 in notification-daemon[621fdfbad000+7000] likely on CPU 6 (core 2, socket 0)
[  768.523469] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[  768.684730] notification-da[14096]: segfault at 3 ip 0000000000000003 sp 00007ffe37243268 error 14 in notification-daemon[60e2808ad000+7000] likely on CPU 6 (core 2, socket 0)
[  768.684743] Code: Unable to access opcode bytes at 0xffffffffffffffd9.
[  768.846533] notification-da[14103]: segfault at 3 ip 0000000000000003 sp 00007ffd02eaf528 error 14 in notification-daemon[61e4af8d5000+7000] likely on CPU 2 (core 2, socket 0)
[  768.846544] Code: Unable to access opcode bytes at 0xffffffffffffffd9.

log after login:

Code: Select all

GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.erikreider.swaync.cc was not provided by any .service files

tried previuous kernel - same result.

tried ~amd64 dbus version - same result.

is this a gentoo issue or hyprlands ?

can someone please check if this also an issue with current stable hyprland version (... using *-9999 version here )



EDIT:

tried with hyprland 0.32.3 version - no change, regarding zombie.

notification issue is solved - depcleaned virtual/notification-daemon x11-libs/startup-notification x11-misc/notification-daemon x11-libs/libnotify

and emerged dunst (only with deps) - working fine now !

zombie is still walking around - but my hyprland only system's working good as always.

[flexibeast]

i'm not familiar with how Hyprland does things - what's calling dbus-update-activation-environment? The process being 'defunct' means that, even though the call is complete, something is still waiting on it for some reason. What's the parent process of the defunct process?

(Also, since you're using OpenRC the '--systemd' option is unnecessary, although in theory it shouldn't hurt ....)

[Anon-E-moose]

It's hyprland

Code: Select all

if (m_sWLRSession /* Session-less Hyprland usually means a nest, don't update the env in that case */ && fork() == 0)
        execl("/bin/sh", "/bin/sh", "-c",
#ifdef USES_SYSTEMD
              "systemctl --user import-environment DISPLAY WAYLAND_DISPLAY HYPRLAND_INSTANCE_SIGNATURE XDG_CURRENT_DESKTOP QT_QPA_PLATFORMTHEME && hash "
              "dbus-update-activation-environment 2>/dev/null && "
#endif
              "dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP HYPRLAND_INSTANCE_SIGNATURE QT_QPA_PLATFORMTHEME",
              nullptr);

I dislike that they don't have the option of avoiding this, as I set all the vars that I need myself.

So I created a patch that removes the above lines when emerging hyprland.

Code: Select all

 void CCompositor::initManagers(eManagersInitStage stage) {
@@ -517,15 +515,6 @@

[CooSee]

thx @Anon-E-moose

tried with patch - zombie process is gone now,

but i'am still getting:

Code: Select all

[LOG] Executing dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP HYPRLAND_INSTANCE_SIGNATURE QT_QPA_PLATFORMTHEME

using @Ja.KooLit dotfiles (v.2.2) - https://github.com/JaKooLit/Hyprland-Dots/

i'am not sure if this has something to do with his dotfiles - i don't even use pipewire or xdg-desktop-portal-hyprland or anykind of QT ebuilds.

i sometimes try new dotfiles on separate disk with endeavour os and when i use dots from https://github.com/prasanthrangan/hyprdots

logs doesn't show dbus-update-activation-environment info at all.

[Anon-E-moose]

Should be coming from Execs.conf,

Code: Select all

# Startup
exec-once = dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP
exec-once = systemctl --user import-environment WAYLAND_DISPLAY XDG_CURRENT_DESKTOP

# Polkit (Polkit Gnome / KDE)
exec-once = $scriptsDir/Polkit.sh

I would remove stuff you don't need from the dot-files

[CooSee]

Should be coming from Execs.conf,

Code: Select all

# Startup
exec-once = dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP
exec-once = systemctl --user import-environment WAYLAND_DISPLAY XDG_CURRENT_DESKTOP

# Polkit (Polkit Gnome / KDE)
exec-once = $scriptsDir/Polkit.sh

I would remove stuff you don't need from the dot-files

already did and also looked in every file

Code: Select all

# Commands & Apps to be executed at launch

$scriptsDir = $HOME/.config/hypr/scripts
$lock = $scriptsDir/LockScreen.sh
$WallpaperPath = $HOME/Pictures/wallpapers

# wallpaper at start
exec-once = swww init
# exec-once = swww query || swww init && swww img ~/Pictures/wallpapers/winter-solstice.jpg  # persistent wallpaper
exec-once = swaybg -m fill -i $HOME/Pictures/wallpapers/winter-solstice.jpg  # using swaybg

# Polkit-Gnome
exec-once = /usr/libexec/polkit-gnome-authentication-agent-1

# Relaunch waybar
exec-once = $scriptsDir/Waybar.sh &

# LockScreen
exec-once = $scriptsDir/LockScreen.sh

# Notification Daemon
exec-once = dunst &

### Rainbow borders
# exec-once = $scriptsDir/RainbowBorders.sh

# Clipboard Manager
exec-once = wl-paste --type text --watch cliphist store
exec-once = wl-paste --type image --watch cliphist store

# ClipBoard History - Rofi Menu
  set $clipboard cliphist list | rofi -dmenu -m -1 -font "Ubuntu Mono Nerd Font 9" -p "Select item to copy" -lines 10 -width 35 | cliphist decode | wl-copy
  set $clipboard-del cliphist list | rofi -dmenu -m -1 primary -font "Ubuntu Mono Nerd Font 9" -p "Select item to delete" -lines 10 -width 35 | cliphist delete

### clean clipboard on every logout
#    set $purge_cliphist [ $purge_cliphist_logout == 'true' ] && rm -f $HOME/.cache/cliphist/db || exit 0
###

[Anon-E-moose]

There's one more spot in hyprland

src/config/ConfigManager.cpp look for dbus-update* not sure what triggers this piece off, as it doesn't seem to trigger on my system.

I don't set env vars in hyprland config files, I preset them in the calling script.
It looks like it might trigger off when it sees env settings in the config file.

[Ja.KooLit]

starting from top

wiki suggest to remove other notifications

https://wiki.gentoo.org/wiki/Dunst#Unme ... on_daemons

[CooSee]

There's one more spot in hyprland

src/config/ConfigManager.cpp look for dbus-update* not sure what triggers this piece off, as it doesn't seem to trigger on my system.

I don't set env vars in hyprland config files, I preset them in the calling script.
It looks like it might trigger off when it sees env settings in the config file.

even without ENV settings or via .profile entries - no difference.

i tested again with newly created users on endeavour os with updated dots from prasanthrangan and also KhingDom - it's the same - so, i must take back my previous statements.

i'll leave it for now, because the created PID doesn't show up at all in htop !

everythings working fine, regarding dots with support from Ja.KooLit <<< thx !

@Anon-E-moose

would you mind sharing your calling script and patch ?

will mark it solved.

[Anon-E-moose]

starting script ~/bin/startw in my case - http://dpaste.com/53A3V8LJA

dbus-* removal - http://dpaste.com/DDV6NRZAZ

In my script, I originally was setting all vars, including pipewire/wireplumber, but I decided I wanted pipewire running even at console,
so I moved a few of the env vars, user dir, etc to .bash_profile, and cleanup of them to .bash_logout,
with care taken to only start once and only remove when last console login logs out.

The script is also set up to add other compositors.

[CooSee]

sorry for delayed response @Anon-E-moose

and thanks for sharing.

the patch is the same - just want to get sure if i did it correctly, because i'am new to create patches and such, after all this years

so, in principle your startw script is like adding ENV vars in users home .profile file.

i use autologin with tinydm and swaylock is starting immediately - acting like a login manager.

greetings

[Anon-E-moose]

This is what I do to create a patch, once I figure out what it needs.

ebuild <ebuild name> unpack
cd /var/tmp/portage/<cat>/<ebuild>/work/<dir>

then copy the file needed to /tmp & edit that file & after changes "diff -u" the original file and the /tmp/changed file
and modify the patch as needed.

Sample

Code: Select all

ebuild hyprland-9999.ebuild unpack

cd /var/tmp/portage/gui-wm/hyprland-9999/work/hyprland-9999/

cp src/Compositor.cpp  /tmp

vi /tmp/Compositor.cpp & whatever changes you need & save

diff -u src/Compositor.cpp /tmp >/tmp/test.patch

=== Now edit header of patch ==== vi /tmp/test.patch
--- src/Compositor.cpp	2023-12-28 05:01:14.823478410 -0600
+++ /tmp/Compositor.cpp	2023-12-28 05:02:18.044228807 -0600
- to -
--- a/src/Compositor.cpp	2023-12-28 05:01:14.823478410 -0600
+++ b/src/Compositor.cpp	2023-12-28 05:02:18.044228807 -0600

and move to /etc/portage/patches/something/something and you're good to go.

And yes startw sets a bunch of vars, checks for exitence of proper dirs, etc then allows me to select which compositor to start while giving me the flexibility add debug or not, etc.