You are not logged in.
Dunst has always been my favorite notification-daemon but recently I was stuck with a problem which is not directly related to dunst though. Currently, I'm on i3wm and looked into the config file but couldn't find anything there that could trigger the following notification
$ dbus-monitor "interface='org.freedesktop.Notifications'"| \grep --line-buffered "member=Notify\|string"
string ":1.98"
string ":1.98"
method call time=1595800385.135299 sender=:1.99 -> destination=:1.79 serial=7 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=Notify
string "notify-send"
string ""
string "UnPlugged"
string ""
string "urgency"
These are the notifications I'm receiving when I plug off the charger for my laptop. I want to locate the file which is associated with sending the notification
UnPlugged
which has
serial=7
. I tried looking out for all possible options over the internet but I don't seem to trace on the solution. Any kind of help is totally appreciable.
Last edited by Tintin5371 (2020-07-29 04:20:50)
Offline
Query all dbus sockets (of the session bus)
dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames
Query the PID attached to a socket (your case of :199)
dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID 'string::1.99'
Inspect the process
cat /proc/<pid here>/cmdline
Offline
That looks like the notification is sent via "notify-send". You could try to put a wrapper in /usr/local/bin that logs the parent process (requires pstree from psmisc)
#!/bin/sh
date >> /tmp/notifylog
echo "notify-send call by: " >> /tmp/notifylog
pstree -caps $$ >> /tmp/notifylog
echo >> /tmp/notifylog
exec /usr/bin/notify-send "$@"
Then look at /tmp/notifylog after the notification has appeared.
Last edited by progandy (2020-07-27 15:12:45)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Thanks for your reply and I tried both the methods mentioned above. So I'm gonna put the output that I got after trying out those methods.
According to seth method the output for
dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID 'string::1.99'
is as follows
method return time=1595881677.567651 sender=org.freedesktop.DBus -> destination=:1.136 serial=3 reply_serial=2
uint32 17105
and after putting the PID value of 17105 in the following command
cat /proc/17105/cmdline
I get the following output
/usr/lib/firefox/firefox
Questions
1. Does it mean that firefox is generating that notification?
2. If that is so then why is it actually doing so and how to stop it?
According to progandy solution I made the script and ran it and this is the following reply to that in /tmp/notifylog
Tue 28 Jul 2020 01:28:36 AM IST
notify-send call by:·
systemd,1 splash
`-terminator,5109 /usr/bin/terminator
¦·`-zsh,20606
¦·······|·`-sh,21036 notif.sh
¦·······|·····`-pstree,21038 -caps 21036
Tue 28 Jul 2020 01:30:31 AM IST
notify-send call by:·
systemd,1 splash
¦·`-terminator,5109 /usr/bin/terminator
¦·····`-zsh,20606
¦·······|·`-sh,21232 notif.sh
¦·······|·····`-pstree,21234 -caps 21232
Questions
1. What should I be looking forward within this output?
2. What is the source of the notification?
I'm really glad for all your suggestion but the solution to my query is still absent or maybe I'm not able to detect it. So it would be really kind of you all to guide me with this.
Last edited by Tintin5371 (2020-07-27 20:45:56)
Offline
It's FF if the process was started before the particular notification appeared - the bus IDs are not static and get recycled all the time.
Looking closer at the actual output, progandy is very much likely right, because the sender gets the bus ID right after the one that dbus-monitor got.
You're not supposed to make "some" script (you named notif.sh) and run it, but shadow notify-send so that when some process calls it, you can trace the call.
I would though suggest to move /usr/bin/notify-send to /usr/bin/notify-send.bin and make the script /usr/bin/notify-send (and adjsut the last line to call /usr/bin/notify-send.bin) because the calling process might use the absolute path.
You then need to wait until the notification pops up again and check the tracing log for the caller.
"UnPlugged" sounds a lot like a response to an event (usb key, headphones, …)?
Offline
I guess I forgot to mention at what instance that notification is triggered. Well it is when I plug in my laptop charger and when I unplug it. So as per your suggestion, I made a small change in the last line of the script
exec /usr/bin/notify-send.bin "$@"
and also changed /usr/bin/notify-send to /usr/bin/notify-send.bin
The output for that is
Tue Jul 28 09:33:35 IST 2020
notify-send call by:·
systemd,1 splash
¦·`-systemd-udevd,289
¦·····`-systemd-udevd,35750
¦·······|·`-su,35878 tintin -c notify-send -u low UnPlugged
¦·······|·····`-notify-send,35883 /bin/notify-send -u low UnPlugged
¦·······|·······¦·`-pstree,35889 -caps 35883
Tue Jul 28 09:38:42 IST 2020
notify-send call by:·
systemd,1 splash
¦·`-systemd-udevd,289
¦·····`-systemd-udevd,36704
¦·······|·`-su,36822 tintin -c notify-send -u low PluggedIn
¦·······|·····`-notify-send,36828 /bin/notify-send -u low PluggedIn
¦·······|·······¦·`-pstree,36831 -caps 36828
Tue Jul 28 09:39:44 IST 2020
notify-send call by:·
systemd,1 splash
¦·`-systemd-udevd,289
¦·····`-systemd-udevd,37300
¦·······|·`-su,37418 tintin -c notify-send -u low UnPlugged
¦·······|·····`-notify-send,37419 /bin/notify-send -u low UnPlugged
¦·······|·······¦·`-pstree,37423 -caps 37419
Tue Jul 28 09:39:47 IST 2020
notify-send call by:·
systemd,1 splash
¦·`-systemd-udevd,289
¦·····`-systemd-udevd,37304
¦·······|·`-su,37625 tintin -c notify-send -u low PluggedIn
¦·······|·····`-notify-send,37626 /bin/notify-send -u low PluggedIn
¦·······|·······¦·`-pstree,37632 -caps 37626
I tried to look into the PID number that is being generated every time the notification is triggered. But it keeps on changing every time the notification is triggered so I'm still struggling to find the source of the script that is triggering this notification.
Offline
The output contains the answer to your question - you added a udev rule that does this.
So check the rules to see which does this. If you didn't write it, you can use pacman to check which package it belongs to.
Offline
Thanks a lot to you seth . As you suggested I found the udev rule under /etc/udev/rules.d which was actually generating that notification. And I guess I created that rule and forgot about it later on and then I was getting paranoid how to find that.
If you didn't write it, you can use pacman to check which package it belongs to.
Mind to explain this part?
Offline
If it wouldn't be you that created the file, using pacman -Qo /etc/udev/rules.d/rulename would give you the package that installed this rule.
Offline