It was already ordered after systemd-udev-settle.service, but that
doesn't do anything if no other units require
systemd-udev-settle.service. This was causing random failures during X
server startup, e.g.
machine# [ 12.691372] display-manager[607]: (EE) open /dev/dri/card0: No such file or directory
http://hydra.nixos.org/build/41062823
* x11 module: don't restart the display manager indefinitely
If the display managers crashes continuously in loops it prevents the
user from switching to the console and try to fix things. Especially
when using the "auto" display manager it can happen quite easily.
* x11 module: fix display manager restart timeouts
It takes more than 1 second to boot the X server.
---
Using the configure option relieves us of the patch and passing the path
via the env var in many places. Also the env var may not be inherited
when components like gdm spawn new sessions.
The following changes are included:
1) install user unit files from upstream dbus
2) use absolute paths to config for --system and --session instances
3) make socket activation of user units configurable
There has been a number of PRs to address this, so this one does the
bare minimum, which is to make the functionality available and
configurable but defaults to off.
Related PRs:
- #18382
- #18222
(cherry picked from commit f7215c9b5b47dfb0a6dbe87ff33d7730729a32e5)
Signed-off-by: Domen Kožar <domen@dev.si>
Regression introduced by bccd75094f.
The mentioned commit removed the pkgs.gtk attribute, but forgot to
change this within the xfce module.
Tested using the xfce NixOS test and it has passed on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We were pulling in 44 MiB of fonts in the default configuration, which
is a bit excessive for headless configurations like EC2
instances. Note that dejavu_minimal ensures that remote X11-forwarded
applications still have a basic font regardless.
Before commit 54fa0cfe4e, the `redshift`
service was run with the environment variable `DISPLAY` set to `:0`.
Commit 54fa0cfe4e changed this to
instead use the value of the `services.xserver.display` configuration
option in the value of the `DISPLAY` variable. In so doing, no default
value was provided for the case where `services.xserver.display` is
`null`.
While the default value of `services.xserver.display` is `0`, use of
which by the `redshift` module would result in `DISPLAY` again being
set to `:0`, `services.xserver.display` may also be `null`, to which
value it is set by, e.g., the `lightdm` module.
In the case that `services.xserver.display` is `null`, with the change
made in commit 54fa0cfe4e, the `DISPLAY`
variable in the environment of the `redshift` service would be set to
`:` (a single colon), which, according to my personal experience,
would result in —
- the `redshift` service failing to start; and
- systemd repeatedly attempting to restart the `redshift` service,
looping indefinitely, while the hapless `redshift` spews error
messages into the journal.
It can be observed that the malformed value of `DISPLAY` is likely at
fault for this issue by executing the following commands in an
ordinary shell, with a suitable `redshift` executable, and the X11
display not already tinted:
- `redshift -O 2500` — This command should reduce the color
temperature of the display (making it more reddish).
- `DISPLAY=':' redshift -O 6500` — This command should raise the
color temperature back up, were it not for the `DISPLAY`
environment variable being set to `:` for it, which should cause
it to, instead, fail with several error messages.
This commit attempts to fix this issue by having the `DISPLAY`
environment variable for the `redshift` service default to its old
value of `:0` in the case that `services.xserver.display` is `null`.
I have tested this solution on NixOS, albeit without the benefit of a
system with multiple displays.
