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.
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?
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 #-----
[Unit]
Description=Test barrierc as a User Service
BindsTo=graphical-session.target
After=graphical-session.target
[Service]
ExecStart=/etc/profiles/per-user/ops/bin/barrierc --name m5 --no-tray --no-daemon [192.168.88.100]:24800
Restart=always
RestartSec=2 #-----
and then placed the following in configuration.nix
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
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?
