Daemonization doesn't work if pueued is not in $PATH

[CheneyWong]

Describe the bug

Pueue daemon 2.0.1
os: Debian 9

Steps to reproduce the bug

run pueued -d
return Error: No such file or directory (os error 2)

I referenced #293
run pueued -vvv
return

17:00:06 [INFO] Parsing config files
17:00:06 [INFO] Checking path: "/root/.config/pueue/pueue.yml"
17:00:06 [INFO] Found config file at: "/root/.config/pueue/pueue.yml"
17:00:06 [INFO] Start restoring state
17:00:06 [DEBUG] (1) pueue_daemon_lib::state_helper: State saved at: "/root/.local/share/pueue/state.json"
^C17:00:10 [INFO] Killing all running tasks
17:00:10 [DEBUG] (7) pueue_daemon_lib::state_helper: State saved at: "/root/.local/share/pueue/state.json"`

no error

retry run pueued -d
return Error: No such file or directory (os error 2)

[Nukesor]

Thanks for the bug report! The forking logic is definitely somewhat untested.
I just noticed that the -vvv flags weren't properly passed to the forked daemon as well.

This has been fixed on the main branch of the repository.
Could you install the newest version and run pueued -d -vvv?
Otherwise it's pretty hard to see what's going wrong.

The new version is now already published in the next patch release.

The main way Pueue is currently being deployed and used is by spinning it up as a systemd service, where it runs without the -d flag. This is why the -d flag is probably somewhat untested :/.

[Nukesor]

Ping @CheneyWong

It would be great if you could try to run this, as I'm not able to reproduce this issue myself :)

[Nukesor]

Ping @CheneyWong

[Nukesor]

Ping @CheneyWong

[alippai]

I wonder if this is because of too new kernel or too new OS is required by pueued.

[alippai]

What I see that it fails before reading the conf or running openat(AT_FDCWD, "/proc/self/stat", O_RDONLY|O_CLOEXEC) = 6 (compared to when no --daemonize is added).
The end of strace:

mmap(NULL, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7ffff74bc000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
clone3({flags=CLONE_VM|CLONE_VFORK, exit_signal=SIGCHLD, stack=0x7ffff74bc000, stack_size=0x9000}, 88) = -1 ENOSYS (Function not implemented)
clone(child_stack=0x7ffff74c4ff0, flags=CLONE_VM|CLONE_VFORK|SIGCHLD) = 2824643
wait4(2824643, NULL, 0, NULL)           = 2824643
munmap(0x7ffff74bc000, 36864)           = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
futex(0x555555a811a8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x555555a81a58, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x555555a82308, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x555555a7fe08, FUTEX_WAKE_PRIVATE, 2147483647) = 3
futex(0x555555a7fd60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x555555a82620, FUTEX_WAIT_BITSET_PRIVATE, 0, NULL, FUTEX_BITSET_MATCH_ANY) = 0
futex(0x7ffff7cd4990, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 2824639, NULL, FUTEX_BITSET_MATCH_ANY) = 0
write(2, "Error: ", 7Error: )                  = 7
write(2, "No such file or directory", 25No such file or directory) = 25
write(2, " (os error ", 11 (os error )             = 11
write(2, "2", 12)                        = 1
write(2, ")", 1))                        = 1
write(2, "\n", 1
)                       = 1
sigaltstack({ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=8192}, NULL) = 0
munmap(0x7ffff7cd5000, 12288)           = 0
exit_group(1)                           = ?
+++ exited with 1 +++```

[Nukesor]

@alippai Could you run this with the newest pueue version?

It should give you a detailed error message about which file/directory is missing.X

[alippai]

Version 3.3.0 doesn't give me the answer. There are cases (different user, different working directory matters) when it works.

I've realized I can run strace -f to get the output from the forked children though.
It's looking for pueued in the PATH and it doesn't find it.
Should this link to the current binary running instead of simply pueue? Or this line using tokio::process instead of std::process?

[Nukesor]

Damn. I didn't think of pueued not being in the PATH. That's why I also couldn't replicate the issue.

The pueued binary in this line should definitely be replaced with the path of the current binary!

[Nukesor]

Very good catch. I didn't think about this possibility at all. I also didn't expect this error to be a "No such file or directory" IO error, since I'm only used to these when actually working with file descriptors.

Thanks a lot for investigating this!

[Nukesor]

I managed to reproduce the issue and fixed it in #473

With that fix, I can no longer reproduce the bug. If you find the time, it would be nice if you could verify the fix :)

Thanks again for your detailed bug report!