Question
Notification settings persistence limits in Kali live root sessions
Rin Nova
0 reputation · 05 May 2021, 15:17 UTC
140.8K views
Loading…
0 reputation · 05 May 2021, 15:17 UTC
Kali is a rolling release with Xfce as the default desktop and standard freedesktop notification support. The distribution does not ship a distro-specific alerting framework, so alert visibility depends on generic desktop components and user preferences.
In the default live boot the environment is non-persistent, and the primary interactive account is root. This combination creates uncertainty about how notification preferences are stored and whether any tuning to reduce noise survives a reboot.
For a setup that aims for useful alerts without notification noise, the decision point is whether alert tuning is expected to persist in live mode and how root-centric operation affects notification daemon behavior.
Is the Xfce notification daemon configuration expected to be retained across reboots in a stock live session without explicit persistence? Does running the session as root change how per-application notification suppression is applied compared with a multi-user desktop? What documented behavior governs persistence of desktop preferences in live mode?
No. In a stock Kali live boot without explicit persistence, Xfce notification daemon settings are not retained across reboots. Running the graphical session as root does not change the freedesktop/Xfce notification suppression mechanism, it only means the single user config lives under /root and there is no multi-user comparison.
The notification daemon runs in the root graphical session and applies the same per-application rules as in a multi-user desktop. The difference in live root use is operational, not protocol: all applications talk to one daemon owned by root, and suppression rules are read from the root user’s xfconf. Without persistence the config is recreated from defaults on each boot, so any tuning to reduce noise is lost.
kalilinuxls -l /root/.config/xfce4/xfce4-notifyd.rc
xfconf-query -c xfce4-notifyd -l
Change a setting in Settings → Notifications, reboot without persistence, and re-run the commands. Reversion to defaults confirms volatility.
Assumption and uncertainty: behavior can differ between Kali rolling images and desktop spins. The above assumes a stock Xfce live image with the standard overlay. If a custom live build or a persistent USB is in use, results will differ.
One diagnostic that changes the recommendation: Is a persistence partition present and does persistence.conf include /root or /root/.config? If yes, settings can survive; if no, treat all Xfce preferences as session-only.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 05 May 2021, 23:36 UTC
In a stock Kali live session, Xfce notification preferences are written to root-owned paths such as /root/.config/xfce4 or the xfconf channel, but those live on the non-persistent overlay and revert after reboot unless a persistence partition explicitly includes /root. Running as root changes config ownership and D-Bus session scope, not xfce4-notifyd's urgency or Do Not Disturb matching; granular per-app suppression remains a daemon limitation regardless of user. Because Kali is rolling, exact keys vary by image. Verify by changing a notification setting, rebooting without persistence, and confirming the value returns to default.