Rationale behind using PartOf= in the systemd service ? #32

beetlebop commented 2023年08月29日 01:21:40 +02:00

I understand that PartOf= shuts down the xsettingsd service when the graphical-session exits.
Well, why not use BindsTo= which in addition will start xsettingsd when a graphical session is launched ?
This is the effect I had expected from having the service unit installed and that I assume most users will want (i.e. to launch xsettingsd automatically upon initiation of their graphical session).

Feel free to correct me if I'm wrong because I am only familiar with systemd superficially.

I understand that PartOf= shuts down the xsettingsd service when the graphical-session exits. Well, why not use BindsTo= which in addition will start xsettingsd when a graphical session is launched ? This is the effect I had expected from having the service unit installed and that I assume most users will want (i.e. to launch xsettingsd automatically upon initiation of their graphical session). Feel free to correct me if I'm wrong because I am only familiar with systemd superficially.

derat commented 2023年08月29日 15:21:58 +02:00

Your familiarity with systemd exceeds mine! I still launch xsettingsd from a .Xresources file.

The systemd config was contributed by @eszlari in db54639d back when this repo was still on GitHub. I'm not sure whether they have a Codeberg account, but you might be able to message them on GitHub if you have an account there to see if BindsTo= would make more sense.

Your familiarity with systemd exceeds mine! I still launch xsettingsd from a .Xresources file. The systemd config was contributed by [@eszlari](https://github.com/eszlari) in [db54639d](https://github.com/derat/xsettingsd/commit/db54639d4305e5ae4cb84cd16ff4d628cc772d35) back when this repo was still on GitHub. I'm not sure whether they have a Codeberg account, but you might be able to message them on GitHub if you have an account there to see if `BindsTo=` would make more sense.

andrei-korshikov commented 2024年04月22日 20:21:03 +02:00

@beetlebop :

why not use BindsTo= which in addition will start xsettingsd when a graphical session is launched ?

Basically, you are asking about starting X application via systemd unit. It is feasible, but environment-dependent, and so there is no point in doing it here.

The current unit file is really good — it has no restriction on starting, and safeguard on graphical-session.target restarting/stopping (which is harmless in case your system doesn't activate this target at all).

The problem with all these BindsTo=, After= and WantedBy= is that graphical-session.target is not ubiquitous (albeit it slowly becomes so). For example, relying on it will break things for i3 users, and I don't think it is the only case. So we just don't have "one unit fits all" option.

And the user should not forget to start scripts from /etc/X11/xinit/xinitrc.d (without 50-systemd-user.sh you'll get Unable to open connection to X server from xsettingsd due to lack of DISPLAY and XAUTHORITY). In theory it could be mitigated with Environment=, but I'm not sure if it is possible to dynamically substitute correct display number. I've never done that, and not going to:)

@beetlebop : > why not use BindsTo= which in addition will start xsettingsd when a graphical session is launched ? Basically, you are asking about starting _X application_ via _systemd unit._ It is feasible, but environment-dependent, and so there is no point in doing it here. The current unit file is really good — it has no restriction on starting, and safeguard on `graphical-session.target` restarting/stopping (which is harmless in case your system doesn't activate this target at all). The problem with all these `BindsTo=`, `After=` and `WantedBy=` is that `graphical-session.target` is not ubiquitous (albeit it slowly becomes so). For example, relying on it will break things for [i3 users](https://github.com/i3/i3/issues/5186), and I don't think it is the only case. So we just don't have "one unit fits all" option. And the user should not forget to start scripts from `/etc/X11/xinit/xinitrc.d` (without `50-systemd-user.sh` you'll get `Unable to open connection to X server` from xsettingsd due to lack of `DISPLAY` and `XAUTHORITY`). In theory it could be mitigated with `Environment=`, but I'm not sure if it is possible to dynamically substitute correct display number. I've never done that, and not going to:)

tkapias commented 2024年07月06日 08:20:39 +02:00

The current service file is not bad because it forces the user to check how he will start the service, xsettingsd should start before other services using the display, like notification icons.

I start my session with .xsession which launch an xsession.target. The only service RequiredBy by it is i3.service, the rest just follows. So I added Wants=xsettingsd.service in i3.service.

There is other ways to do it, I think that the README could just state that xsettingsd.service should be started or wanted somewhere in the init/login process by the user.

The current service file is not bad because it forces the user to check how he will start the service, xsettingsd should start before other services using the display, like notification icons. I start my session with .xsession which launch an xsession.target. The only service RequiredBy by it is i3.service, the rest just follows. So I added Wants=xsettingsd.service in i3.service. There is other ways to do it, I think that the README could just state that xsettingsd.service should be started or wanted somewhere in the init/login process by the user.