[Bug]

[paranormal]

Describe the bug

Remote configuration doesn't work when set up following documentation.

Steps to reproduce

1) tcp method, it just wouldn't listen on a port even when said to do this (with or without keys)

shared:
  use_unix_socket: false
  host: blah
  port: blah2

2) Using ssh with socket forwarding somehow works, but: the documentation mention the key -u which does not exist. the key -c and the nested profile doesn't work but if I put the configuration from nested profile into root it starts working

this would work

shared
  read_local_logs     false
  use_unix_socket     true
  unix_socket_path    /tmp/local.socket
  daemon_cert         ~/.local/share/pueue/certs/remote_daemon.cert
  daemon_key          ~/.local/share/pueue/certs/remote_daemon.key
  shared_secret_path  ~/.local/share/pueue/remote_shared_secret

but this wouldn't

shared: blabla
profiles:
  host:
    shared: here goes the previous section

Debug logs (if relevant)

-vvv doesn't help much with this issue, basically you are blind and nothing works at this stage.

Operating system

nixos-23.11

Pueue version

v3.3.3

Additional context

No response

[Nukesor]

First of all, which documentation are you talking about?

I don't know anything about a -u flag. The -c flag can be used to pass a path to a different configuration file.

Also what exactly are you trying to accomplish? Showing an example with stuff like blah isn't really helpful, i'm not sure what I should diagnose over here.

Your second config works, as it's using unix sockets, which are local.

Your third example uses the profiles feature, which is something entirely different and requires you to use the -p flag to select a specific profile.

[paranormal]

This one https://github.com/Nukesor/pueue/wiki/Connect-to-remote

I'm trying to replace tmux with your software ) for long running tasks on remote server. With systemd lingering seems the right way to go.

With first configuration: setting port and ip in the top shared section doesn't make the daemon listen on port. I can't connect to in with network tools like telnet & can't see it in netstat output.

The use of -u is at the end of mentioned documentation. I think I took the suggestion to use -c and applied it and the end of documentation where clearly -p is needed. I'll have another bout setting things up and post tried configuration.

[Nukesor]

TCP

So this should always work. You have to disable unix sockets though for it to work, but it seems you have already done this.

On my Pc, pueued starts up with this config quite fine:

shared:
  use_unix_socket: false
  host: 127.0.0.1
  port: "6924"

It then also shows up in a netstat -tulpn and I can connect to it via client.

tcp        0      0 127.0.0.1:6924          0.0.0.0:*               LISTEN      25072/pueued

Can you please show the daemon log output? On my side the log looks like this:

11:52:11 [INFO] Parsing config files
11:52:11 [INFO] Checking path: "/home/nuke/.config/pueue/pueue.yml"
11:52:11 [INFO] Found config file at: "/home/nuke/.config/pueue/pueue.yml"
11:52:11 [INFO] Restoring state
11:52:11 [DEBUG] (1) pueue::daemon::state_helper: State saved at: "/home/nuke/.local/share/pueue/state.json"
11:52:11 [INFO] Binding to address: 127.0.0.1:6924

You can see that it binds to the address, if this log doesn't show up on your side, something's fucky.

Profiles

I'm also not sure what's wrong over here.

I have this test config setup:

shared:
  use_unix_socket: false
  host: 127.0.0.1
  port: "6924"
profiles:
  omfg:
    shared:
      use_unix_socket: true
      host: 127.0.0.1
      port: "6924"

Calling that profile now results in the unix socket being used as expected:

[nuke:~] 12s 1! pueued -vvv -p omfg
11:56:14 [INFO] Parsing config files
11:56:14 [INFO] Checking path: "/home/nuke/.config/pueue/pueue.yml"
11:56:14 [INFO] Found config file at: "/home/nuke/.config/pueue/pueue.yml"
11:56:14 [INFO] Restoring state
11:56:14 [DEBUG] (1) pueue::daemon::state_helper: State saved at: "/home/nuke/.local/share/pueue/state.json"
11:56:14 [INFO] Using unix socket at: "/run/user/1000/pueue_nuke.socket"

Could you provide logs for this as well?

-u flag

I can no longer recall to have written this and I didn't even remember that something like this is possible! It seems I checked that this could work a few years ago, but I never actually used it.

Thanks for pointing that out, I was really confused :D

[paranormal]

The issue is on my side, I should had been more diligent before rising an issue, I did it when -u didn't work as an act of frustration. May I at least push a change in documentation to compensate my wrongdoing?

nixos runs things differently, this is why editing configuration made no difference. Here is systemctl --user status pueued.service output where the real path to config can be seen.

● pueued.service - Pueue Daemon - CLI process scheduler and manager
     Loaded: loaded (/home/.config/systemd/user/pueued.service; enabled; preset: enabled)
     Active: active (running) since Fri 2024-03-15 19:57:13 EET; 14s ago
   Main PID: 2201925 (pueued)
      Tasks: 7 (limit: 9506)
     Memory: 700.0K
        CPU: 4ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pueued.service
             └─2201925 /nix/store/hj2b47frl146lm7pqhivpqi7mchvppyc-pueue-3.3.1/bin/pueued -v -c /nix/store/zr892ibwxs8qkcpwj83z996ksq4cr9zc-pueue.yaml

After configuring it in nix's home-manager like this:

  services.pueue = {
    enable = true;
    settings = {
      shared = { use_unix_socket = false; host = "127.0.0.1"; port = "6924"; };
    };
  };

I can see it in netstat as expected tcp 0 0 127.0.0.1:6924

[Nukesor]

Feel free! The wiki can be edited by everyone and many parts have already been updated/edited by the community at this point :)

[paranormal]

You have cleaned it already. tnx