Hey! I cargo culted that line from other projects. I'm not sure if it's actually needed. Could try removing it (and the dbus one below) and see if everything still works?

The actually important variables like WAYLAND_DISPLAY are imported by the niri binary itself.

I believe we'd still want the WAYLAND_DISPLAY and XDG_... variables to end up in D-Bus and systemd after niri is ready and before too many (or any at all) other new processes have started

I had a related conversation with the COSMIC folks about this, but that solution doesn't map cleanly to the infrastructure we have here: pop-os/cosmic-session#31

I believe we'd still want the WAYLAND_DISPLAY and XDG_... variables to end up in D-Bus and systemd after niri is ready and before too many (or any at all) other new processes have started

Yeah, the niri binary takes care of that.

Is there a way to disable activation environment management and readiness notification at runtime? For a case of external service manager? Like via a variable? Or to configure which variables are exported to activation environments?

Uhh, not really? Not sure why you'd want to disable that.

Also, a hint: dbus-update-activation-environment is not needed if dbus is provided by dbus-broker (it reuses systemd environment). And I did not find any environment cleanup handling (which classic dbus has troubles with).

Uhh, not really? Not sure why you'd want to disable that.

So it would be handled properly by a session manager, and dependent services would not be started prematurely.

Also, a hint: dbus-update-activation-environment is not needed if dbus is provided by dbus-broker

And if it's not provided by dbus-broker? :) Some distros that run niri don't even use systemd. It's easier to have a common code path.

And I did not find any environment cleanup handling

It's in the resources/niri-session script.

So it would be handled properly by a session manager, and dependent services would not be started prematurely.

But it is already properly handled and dependent services are not started prematurely.. I guess I don't really understand why uwsm is needed for niri which already provides a working systemd integration?

It has its features, like login shell integration, idempotent environment management (including cleanup and dbus/dbus-broker issues workarounds), clean unit shutdown, various helpers, desktop entry launch wrapper, etc...

Anyway, people use it and I got a bug report which appeared like a premature compositor unit readiness, but most likely it is not. If compositor exports essential variables to activation environments and signals unit readiness by itself, it is great there is no incompatibility here. The only remaining issue would be additional variables: if user tries to add more variables via uwsm finalize ... in compositor's startup, those vars will most likely come too late because compositor already notified startup at this point.

Similar issue with Hyprland was resolved by a couple of environment switches (one, two) which are used on uwsm's side via a plugin. Labwc also has LABWC_UPDATE_ACTIVATION_ENV switch, and it does not hardcode unit readiness notification.

I guess it's not too big a deal to gate sd notify behind an env var, but is that really correct here? Like, my niri.service has Type=notify, which means that niri must notify its readiness. And if you're planning to use a custom service instead of niri.service, then you should already be able to set up the dependencies in such a way that niri by itself will not activate graphical-session.target, and instead for example activate a uwsm target that will add any extra variables and then activate graphical-session.target?

I guess it's not too big a deal to gate sd notify behind an env var, but is that really correct here?

There is always a possibility that a compositor can be integrated into some overarching structure like a DE or a session manager. In this case a way to hand off session/unit/environment operations would be useful.

niri.service has Type=notify, which means that niri must notify its readiness.

[email protected] has:

Type=notify
NotifyAccess=all

Which allows receiving notification from child processes, that is uwsm finalize command, which has to be run by compositor, to also get vars from it. It exports WAYLAND_DISPLAY (always) and DISPLAY (if set), and any other variables that were requested by user or plugin, also maintaining a cleanup list.

And if you're planning to use a custom service instead of niri.service, then you should already be able to set up the dependencies in such a way that niri by itself will not activate graphical-session.target, and instead for example activate a uwsm target that will add any extra variables and then activate graphical-session.target?

Triggering graphical-session.target via a different unit is an idea worth investigating, thanks! I guess it can be a process that watches activation environment for WAYLAND_DISPLAY to appear. But it is not obvious how to maintain a cleanup list if compositor puts more variables into activation environment by itself. And how to access any var that a compositor might set, but not export to activation environment (I'm thinking general cases here).

I see you're experimenting with this idea; let me know if it works out and what changes, if any, would be needed if it does.

My experiments will at least yield a delayer for graphical-session.target that waits for WAYLAND_DISPLAY to appear. Probably, also a workaround for adding more vars from compositor's environment to activation environment while delayer specifically waits for those vars, even after compositor already dealt with WAYLAND_DISPLAY and unit readiness by itself. Unfortunately I do not yet see a generic automagical solution that accounts for all possible compositor's behaviors without compositor-specific preconfiguration.

As for changes, as I said above:

There is always a possibility that a compositor can be integrated into some overarching structure like a DE or a session manager. In this case a way to hand off session/unit/environment operations would be useful.

So adding some kind of a switch would be nice in any case. No other changes required.

I added NIRI_DISABLE_SYSTEM_MANAGER_NOTIFY env var, setting it 1 should suppress both systemd and NOTIFY_FD notification. Could you try if that's sufficient for you?

I don't think suppressing env import should be that necessary?

Thank you!

It went better than I expected.

Interesting, so disabling sd notify isn't necessary after all?

In case of uwsm now it isn't.