-
Notifications
You must be signed in to change notification settings - Fork 69
nixpkgs services.lorri
requires reboot for the user lorri.socket to appear
#374
Comments
Doesn’t require reboot, just a reload of the user daemon:
This is a regression in nixpkgs: NixOS/nixpkgs@b20a0e4#r38459106 |
@Profpatsch I'd like to ask a (possibly naive) question about this issue. Why is the socket required at all? It seems like the weird interaction with systemd sockets is one of the major pain points for new users. As such, would it not be better to just have the very resource-light |
the However I’m fairly sure that the issue above pertains to the |
I have an issue I think is related where the lorri socket doesn't seem to reactivate after stopping it or reloading it:
|
I am seeing a similar thing as @codygman
|
We are swallowing varlink errors in the check, so I assume there is a varlink error message here that we silently ignore: Lines 24 to 32 in 93d9301
cc @curiousleo @nyarly Lemme write a patch that shows what is going on. |
Please check out #441 and try reproducing the problem after running |
lorri self-upgrade won't work for me. I updated to the latest with niv though in this commit. It seems to me that for some reason the new symbolic link to lorri isn't being loaded into systemd. This is similar to me in how I have to restart emacs after installing packages with nix because it's a wrapper that modifes the load path. I'm not sure the way to workaround this issue here though. Here are the results of debugging I mostly pasted from this commit:
Indeed, that doesn't exist:
Here's the lorri unit file:
Hmm:
Well.. that is right
So the errors above aren't relevant... so then why isn't the socket
I cd into a directory that uses lorri:
Okay... direnv allow in my experince has never failed to ping lorri so
Surely we've generated some logs by now:
Okay.. what if we do a reload as recommended in #374 (comment)
No luck.
|
After rebooting things worked just fine and it doesn't look like anything changed: [cody@nixos:~/hci]$ systemctl --user cat lorri
# /nix/store/nm14xpfpd2pirj1v2pvpd1kwk1yi02mh-home-manager-files/.config/systemd/user/lorri.service
[Service]
Environment=PATH=/nix/store/15wpim5v22189mrfrm6n8ggg410n3rvi-nix-2.3.6/bin:/nix/store/r1jr2v6afyhc19yx9i1ck230x9987c6q-git-2.27.0/bin:/nix/store/ldh4iwq6dxsv6cj78gv060wq9xa17n1h-gnutar-1.32/bin:/nix/store/yir8n5jfmcdmf0hyk712kl97krmdshlg-gzip-1.10/bin
ExecStart=/nix/store/7988ydmqdwk1p64sjysmi06bq523nbac-lorri/bin/lorri daemon
PrivateTmp=true
ProtectHome=read-only
ProtectSystem=strict
Restart=on-failure
[Unit]
After=lorri.socket
Description=lorri build daemon
RefuseManualStart=true
Requires=lorri.socket Maybe this is more of a systemd/nixos bug? Maybe NixOS/nixpkgs#49528 is related here. |
Ah right, if you want to test the NixOS service you will have to put the
new lorri version in your NixOS config. If you use nixpkgs unstable, there
should be a new lorri version (0.2) in NixOS now, which we released a week
or so ago. This includes the PR I mentioned above.
…On Sun, Jul 12, 2020 at 11:56 PM Cody Goodman ***@***.***> wrote:
After rebooting things worked just fine and it doesn't look like anything
changed:
***@***.***:~/hci]$ systemctl --user cat lorri# /nix/store/nm14xpfpd2pirj1v2pvpd1kwk1yi02mh-home-manager-files/.config/systemd/user/lorri.service
[Service]
Environment=PATH=/nix/store/15wpim5v22189mrfrm6n8ggg410n3rvi-nix-2.3.6/bin:/nix/store/r1jr2v6afyhc19yx9i1ck230x9987c6q-git-2.27.0/bin:/nix/store/ldh4iwq6dxsv6cj78gv060wq9xa17n1h-gnutar-1.32/bin:/nix/store/yir8n5jfmcdmf0hyk712kl97krmdshlg-gzip-1.10/bin
ExecStart=/nix/store/7988ydmqdwk1p64sjysmi06bq523nbac-lorri/bin/lorri daemon
PrivateTmp=true
ProtectHome=read-only
ProtectSystem=strict
Restart=on-failure
[Unit]
After=lorri.socket
Description=lorri build daemon
RefuseManualStart=true
Requires=lorri.socket
Maybe this is more of a systemd/nixos bug? Maybe NixOS/nixpkgs#49528
<NixOS/nixpkgs#49528> is related here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#374 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYB5ZWKMLJAMGLCYHIF2LLR3IWPPANCNFSM4MG5AFRA>
.
|
In the README it's suggested to do
after adding
(Using nixos-unstable and lorri installed is v1.2.0 if it matters) I did not check if the whole thing works, but the fact that there's an error message when applying recipe from README is worrying. |
Describe the bug
When putting
systemd.lorri.enable = true;
in your system config, you would assume that the socket unit appears immediately after a system switch, but in fact it only does after reboot. Logging out and into the user account does not help.To Reproduce
lorri.service.enable = true;
and switch your system (at least nixos 20.03)systemctl --user
does not have any lorri service or socketsystemctl --user
has thelorri.socket
nowExpected behavior
The socket file should appear immediately after the NixOS system switch.
Additional context
Grepping through
nixpkgs
forsystemd.user.sockets
(and similar) only yields like three results, so it might be that starting a.socket
unit for the user daemon is just not a common use-case and we’re in uncharted territory.Possible solutions I can think of:
systemd.user
config to update on switch. Probably hard, might even be impossible.cc @curiousleo
The text was updated successfully, but these errors were encountered: