earlyoom icon indicating copy to clipboard operation
earlyoom copied to clipboard

No desktop notification are triggered by earlyoom's default configuration

Open RiverOnVenus opened this issue 3 years ago • 4 comments

System Information

Operating System: Arch Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Graphics Platform: X11

Software and Version

Name            : earlyoom
Version         : 1.7-1

Name            : systembus-notify
Version         : 1.1-1

Description

I installed and started according to the README, without modifying any configuration files.

➜ cat /etc/default/earlyoom 
# Default settings for earlyoom. This file is sourced by /bin/sh from
# /etc/init.d/earlyoom or by systemd from earlyoom.service.

# Options to pass to earlyoom
EARLYOOM_ARGS="-r 3600 -n --avoid '(^|/)(init|systemd|Xorg|sshd)$'"

# Examples:

# Print memory report every second instead of every minute
# EARLYOOM_ARGS="-r 1"

# Available minimum memory 5%
# EARLYOOM_ARGS="-m 5"

# Available minimum memory 15% and free minimum swap 5%
# EARLYOOM_ARGS="-m 15 -s 5"

# Avoid killing processes whose name matches this regexp
# EARLYOOM_ARGS="--avoid '(^|/)(init|X|sshd|firefox)$'"

# See more at `earlyoom -h'
● earlyoom.service - Early OOM Daemon
     Loaded: loaded (/usr/lib/systemd/system/earlyoom.service; enabled; vendor preset: disabled)
     Active: active (running) since Tue 2022-04-19 11:39:44 CST; 8min ago
       Docs: man:earlyoom(1)
             https://github.com/rfjakob/earlyoom
   Main PID: 417 (earlyoom)
      Tasks: 1 (limit: 10)
     Memory: 4.7M (max: 50.0M available: 45.2M)
        CPU: 57ms
     CGroup: /system.slice/earlyoom.service
             └─417 /usr/bin/earlyoom -r 3600 -n --avoid "(^|/)(init|systemd|Xorg|sshd)\$"

Apr 19 11:41:25 zhui-pc earlyoom[417]: mem avail:    44 of  7727 MiB ( 0.57%), swap free: 1211 of 15453 MiB ( 7.84%)
Apr 19 11:41:25 zhui-pc earlyoom[417]: low memory! at or below SIGTERM limits: mem 10.00%, swap 10.00%
Apr 19 11:41:25 zhui-pc earlyoom[417]: sending SIGTERM to process 1687 uid 1000 "tail": badness 1243, VmRSS 6642 MiB
Apr 19 11:41:26 zhui-pc earlyoom[417]: process exited after 1.4 seconds
Apr 19 11:41:26 zhui-pc earlyoom[1698]: Failed to open connection to "system" message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Apr 19 11:53:34 zhui-pc earlyoom[417]: mem avail:   113 of  7727 MiB ( 1.47%), swap free: 1223 of 15453 MiB ( 7.92%)
Apr 19 11:53:34 zhui-pc earlyoom[417]: low memory! at or below SIGTERM limits: mem 10.00%, swap 10.00%
Apr 19 11:53:34 zhui-pc earlyoom[417]: sending SIGTERM to process 3216 uid 1000 "tail": badness 1212, VmRSS 6222 MiB
Apr 19 11:53:35 zhui-pc earlyoom[417]: process exited after 1.3 seconds
Apr 19 11:53:35 zhui-pc earlyoom[3232]: Failed to open connection to "system" message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Service started by default configuration with the -n parameter, but without desktop notification, after I start manually with earlyoom -n there are notification.

RiverOnVenus avatar Apr 19 '22 04:04 RiverOnVenus

The service started under the default configuration, dbus-send works fine, but earlyoom does not trigger. image

Use earlyoom -n to start manually and both will trigger. image

RiverOnVenus avatar Apr 19 '22 04:04 RiverOnVenus

Ive had the same issue with this. Also on Arch Linux A simple solution I've found is commenting out DynamicUser=true in the earlyoom.service

not too ideal as it runs as root, rather then its own user. maybe there's a better way to handle it.

taiyu-len avatar Jun 14 '22 10:06 taiyu-len

Same issue, also on arch.

Ive had the same issue with this. Also on Arch Linux A simple solution I've found is commenting out DynamicUser=true in the earlyoom.service

not too ideal as it runs as root, rather then its own user. maybe there's a better way to handle it.

In my opinion, it's kinda okay for this kind of app to run as root, since it needs some "priority" to be able to do it's job when things are bad. Okay, you may argument that "It's a potential vulnerability to be exploited", and I agree; but rather have this "potential vulnerability" than getting things killed without any "alert" nor anything like this.

I have an suggestion for a feature, but I'll put on it's own issue.

ForumPlayer avatar Apr 16 '23 12:04 ForumPlayer

Operating System: Arch Linux 
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.8.9-zen1-2-zen (64-bit)
Graphics Platform: Wayland

This is currently working without having to change earlyoom.service.

samuel-jimenez avatar May 09 '24 17:05 samuel-jimenez