Hello everyone!
As an experiment I wrote a session manager for standalone wayland
compositors that utilizes systemd user-level daemon features for
graphical sessions: https://github.com/Vladimir-csp/uwsm
It can either manage targets by itself and launch wayland session in a
scope, or launch
On 10/02/2023 12.51, Mantas Mikulėnas wrote:
Also systemd.special manual recommends putting display servers
into session.slice. But in case of a wayland compositor it is
impossible to separate it from the apps, because the compositor
handles keyboard shortcuts (which launch apps
On 10/02/2023 12.51, Mantas Mikulėnas wrote:
The whole graphical session (wayland-wm@${WM}.service or
wayland-wm-${WM}.scope depending on uwsm mode of operation) and
apps live in the app.slice. Which seems to be in accordance to
app.slice description in systemd.special manual.
On 10/02/2023 12.51, Mantas Mikulėnas wrote:
Also systemd.special manual recommends putting display servers
into session.slice. But in case of a wayland compositor it is
impossible to separate it from the apps, because the compositor
handles keyboard shortcuts (which launch apps
Hello again.
I have a question about XDG autostart implementation. Why are units
generated with "@autostart" specifier and not some kind of
"app-xdg-autostart-" prefix? Autostart seems to be a category of units,
not an instance for specific unit. Why put it in a specifier? Is there a
use case
Hello.
In context of a modern systemd-managed user session, is there a separate
dbus activation environment, or is it merged with systemd? If one
intends to manage environment variables, is systemctl (or
org.freedesktop.systemd1.Manager Environment) enough?
A variable added by dbus-update-ac
So I'm seeing an artifact of dbus-broker.
Is it possible to unset a variable from native dbus execution environment?
On 08/01/2024 19.21, Mantas Mikulėnas wrote:
The traditional dbus-daemon keeps a separate environment for services
it spawns directly (i.e. those that don't specify SystemdServic
On 08/01/2024 22.26, Simon McVittie wrote:
It is not possible to unset a variable in the dbus-daemon's activation
environment, or with `dbus-update-activation-environment`: that's an
API limitation in the org.freedesktop.DBus interface. I've thought about
adding an UnsetAndSetActivationEnvironmen
At least signals seem to be sent only only once.
A process in a login shell can wait for TERM (and two HUPs if on
console), wait a bit after this, then safely fork cleanup tasks and exit
before KILL comes.
On 15/01/2024 13.08, Lennart Poettering wrote:
When the goal is to shut down a service
Hello everyone!
I'm noticing an issue on my system (Debian sid) on shutdown. Wlroots
compositors try to communicate release of session to logind, but logind
is already gone, so conflicts arise due to activation attempts, journal
is spammed with stuff like this:
Jun 29 10:38:13 hostname syste
Hello again.
What would be the proper way of transferring environment variables set
by pam for login sessions into systemd user service activation
environment? Is there a tool or setting that does this automatically?
The problem is, in context of a login session it is hard to tell which
vars
11 matches
Mail list logo
