Login script seems to run twice

I’m realtively new to NixOS and running into some integration issues.

My user config in configuration.nix contains:

users.users.ops = {
isNormalUser = true;
description = “ops”;
extraGroups = [ “networkmanager” “wheel” ];
packages = with pkgs; [

programs.bash.loginShellInit = ‘’
barrierc --debug INFO --name m5 --restart --log /tmp/barrier.log --no-tray --daemon []:24800

When I log in as ops, two issues arise:
i) two instances of the barrier client are launched as evidenced by by $ ps -fu ops | grep barr

ops 2045 1 0 20:00 ? 00:00:01 /nix/store/8f9x0kh7yip6hy9q7cz5431ak5vs563j-barrier-2.4.0/bin/.barrierc-wrapped --debug INFO --name m5 --restart --log /tmp/barrier.log --no-tray --daemon []:24800
ops 2049 1 0 20:00 ? 00:00:01 /nix/store/8f9x0kh7yip6hy9q7cz5431ak5vs563j-barrier-2.4.0/bin/.barrierc-wrapped --debug INFO --name m5 --restart --log /tmp/barrier.log --no-tray --daemon []:24800
ops 2698 2607 0 20:13 pts/0 00:00:00 grep barr

ii) the log /tmp/barrier.log does not get created

Other than that it works as expected and I am able to kill either barrierc process and it continues to work.

I use barrier on ubuntu 20.04 and opensuse 15.2, 15.3 and 15.4 successfully although in those cases I launch it from ~/.profile

I tried launching barrier from ~/.profile on nixos with the same result outlined above.

Should I be configuring things differently or is this a feature/bug that should be looked into?

Thanks in advance.

Sounds to me like you are launching two login shells. Or is there anything in your ~/.bashrc that would invoke the login shell profile again? Do you start even more barrier clients as you open more terminals? It’s probably something along those lines anyway; note that “login shell” is not just the shell started when you log in, it includes any shell launched with bash --login, which can be done in numerous ways (including a bunch that don’t involve X11 and will therefore fail to start barrierc).

ps --forest would help see what process launched which, so you can determine the origin of the various instances.

I’d argue the way you’re doing it on ubuntu/suse is wrong too. User services should be launched with systemd user units, precisely to avoid problems like this.

Personally, I use home-manager for this, and I define my barrier client service here. It’s instanced by host so that I can easily switch on a different network, and I launch the service manually, but it’s pretty easy to make that service autostart on login instead.

You can probably achieve something similar with systemd.user.units, but I have to admit I’ve never used NixOS user units. It looks really similar at face value, though, see e.g. the waybar service: nixpkgs/waybar.nix at a841e262264e48722dccc8469f066068146e406b · NixOS/nixpkgs · GitHub

Thank you for the well considered reply!

  • there is no ~/.profile from when I moved the call to barrier inside configuration.nix
  • more barrier clients do not appear as I open more terminals
  • I agree that the way I’m doing it on ubuntu and opensuse is not ideal and I’ll look at doing it differently
  • I will look into systemd user units (great suggestion)

I was wondering if there is documentation available as to the steps that actually take place when logging into a gnome desktop on nixos. I noticed that ~/.bash_login and ~/.bash_profile get ignored so I’m thinking things work differently on nixos. Maybe a ~/.profile is implied by the system configuration even though there is none in ~, and thus the other login startup file options are being ignored?

Thanks again for a great reply!

Sadly, not afaik. It’s also a bit of a pain to trace. It is for most distros I’ve touched, to be fair. Most of that lives around here: nixpkgs/nixos/modules/services/x11/display-managers at nixos-22.11 · NixOS/nixpkgs · GitHub

This is luckily not related to the session startup files.

NixOS uses the bash defaults, whereas ubuntu’s /etc/bashrc misbehaves (well, in my eyes) and loads ~/.bash_profile and ~/.bash_login in situations where bash would not by default. You can look up the bash defaults in the bash man pages.

Notably, an interactive shell will read neither of those two files.

NixOS only does a little bit on top of that, all of that logic lives in /etc/bashrc.

The odd thing is that if I create ~/.profile, it gets run when I login to the desktop. If I rename it to either ~/.bash_login or ~/.bash_profile, it gets ignored. This seems inconsistent with the behavior described in the bash man pages.

I’ll look at /etc/bashrc in detail to see what’s going on there.



I created the following “tst.service” file in ~/.config/systemd/user
Description=Test barrierc as a User Service

ExecStart=/etc/profiles/per-user/ops/bin/barrierc --name m5 --no-tray --no-daemon []:24800
and then placed the following in configuration.nix

programs.bash.loginShellInit = ‘’
systemctl --user start tst.service

It is working great and has addressed the issues originally identfied.

If you have any further thoughts on this as being a sensible approach (or not) I would be appreciative.

Many thanks for your help!

1 Like

Instead of this, set the Install section for your unit:

Then enable the unit with systemctl --user enable tst.service. Systemd will then automatically start your unit when your graphical session starts, and you won’t need to abuse your bash login to launch services.

The next step will be to generate that file with NixOS so you don’t need to manually create/enable it, but probably makes sense to get used to it like this for the moment :slight_smile:

That’s indeed odd; I use zsh these days, but ~/.bash_profile definitely used to work for me in the past, and I’ve seen others use it recently. I wonder why it doesn’t work in your case.

Great suggestion (to disabuse the bash login). Love it!

I’m ready for the next step (generate unit file from NixOS) and I’m going going to look into the various systemd.user… options. Is that what you had in mind or were you thinking along different lines?

1 Like

Yep, that’s what you would look at, the waybar module I mentioned earlier is a good example.