Custom scripts aren't working with the polybar module when it's run as a service

JonathanReeve commented 3 years ago

Issue description

I have a custom script for showing my emacs clocked-in time in Polybar. It works fine if I start polybar manually, but for some reason the Polybar module doesn't work when it's started by the systemd polybar service configured with home-manager.

Here's how I'm calling the Polybar module in home-manager. I bet it's an environment issue, but I don't see anything in my logs.

Meta

Maintainer CC

@uvNikita @rycee

Technical details

system: "x86_64-linux"
host os: Linux 5.9.8, NixOS, 21.03pre251971.a371c107116 (Okapi)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.8
channels(root): "nixos-21.03pre251971.a371c107116"
channels(jon): "home-manager, nixpkgs-21.03pre251181.dd1b7e377f6"
nixpkgs: /home/jon/.nix-defexpr/channels/nixpkgs

berbiche commented 3 years ago

Most likely an environment issue. a) You could systemctl --user import-environment as part of starting your WM b) Set the enviromnent of the systemd service systemd.user.services.polybar.Service.Environment with the required path

uvNikita commented 3 years ago

A good starting point for troubleshooting would be to look at polybar service logs:

$ journalctl --user -u polybar.service

JonathanReeve commented 3 years ago

This took me forever to figure out, but a workaround I can live with is that I just used the full paths /run/current-system/... instead of the command names, and now everything is working as expected. The environment stuff didn't really help, unfortunately, and I wasn't seeing anything in the logs, either.

wochap commented 3 years ago

I had the same problem, another workaround is to initialize Polybar in the Window Manager config file, in my situation i use BSPWM so i run polybar in my bspwmrc file https://github.com/wochap/nix-config/commit/a6b0dcad4882ad27fac1f7d65f5b56bd24c8a77b

nrdsp commented 2 years ago

Was having the same issue. Removing polybar top & from services.polybar.script and adding it to xsession.windowManager.i3.config did the trick for me (thanks @wochap for the hint):

startup = [
...
    {
        command = "polybar top &";
        always = true;
        notification = false;
    }

CarlosMendonca commented 2 years ago

This is a bit old and possibly stale, but I figured I'd share my solution that keeps polybar running through systemd and avoids having to make sure all commands and scripts include the full path, which can be either resolved by the Nix parsers or hard-coded on config files. Thanks to the messages above, I was able to identify the issue.

If you set up a polybar module to output its environment variables to a text file, e.g.:

click-left=/run/current-system/sw/bin/printenv > ~/debug.txt

... you will notice that the $PATH variable is not what's reported by systemd --user show-environment. This is because the home-manager polybar.nix file hard-coded the systemd PATH in such a way, that ignores all other paths. You can see that by cat ˜/.config/systemd/user/polybar.service.

Source for this is here.

The way around it is to unset that configuration on your polybar system declaration, something like:

systemd.user.polybar.service = {
  Service.Environment = lib.mkForce ""; # to override the package's default configuration
  Service.PassEnvironment = "PATH"; # so that the entire PATH is passed to this service (alternatively, you can import the entire PATH to systemd at startup, which I'm not sure is recommended
}

For me, that successfully allowed systemd to import the PATH that was set on systemd --user show-environment, which is my systems $PATH.

By the way, this seems connected to this issue. This commit added additional paths to polybar's systemd config, but doesn't solve the fundamental problem, that systemd should be configured with the system's path, and not hard-coded, IMO.

BeatScherrer commented 6 months ago

This is a bit old and possibly stale, but I figured I'd share my solution that keeps polybar running through systemd and avoids having to make sure all commands and scripts include the full path, which can be either resolved by the Nix parsers or hard-coded on config files. Thanks to the messages above, I was able to identify the issue.

If you set up a polybar module to output its environment variables to a text file, e.g.:
click-left=/run/current-system/sw/bin/printenv > ~/debug.txt
... you will notice that the $PATH variable is not what's reported by systemd --user show-environment. This is because the home-manager polybar.nix file hard-coded the systemd PATH in such a way, that ignores all other paths. You can see that by cat ˜/.config/systemd/user/polybar.service.

Source for this is here.

The way around it is to unset that configuration on your polybar system declaration, something like:
systemd.user.polybar.service = {
  Service.Environment = lib.mkForce ""; # to override the package's default configuration
  Service.PassEnvironment = "PATH"; # so that the entire PATH is passed to this service (alternatively, you can import the entire PATH to systemd at startup, which I'm not sure is recommended
}
For me, that successfully allowed systemd to import the PATH that was set on systemd --user show-environment, which is my systems $PATH.

By the way, this seems connected to this issue. This commit added additional paths to polybar's systemd config, but doesn't solve the fundamental problem, that systemd should be configured with the system's path, and not hard-coded, IMO.

The following worked but required a slightly different option:

  # NOTE: Fix polybar service env
  systemd.user.services.polybar = {
    Service.Environment = lib.mkForce ""; # to override the package's default configuration
    Service.PassEnvironment = "PATH"; # so that the entire PATH is passed to this service (alternatively, you can import the entire PATH to systemd at startup, which I'm not sure is recommended
  };

nix-community / home-manager