[BUG] IO error about pueue HOT 9 CLOSED

I'm familiar with rust and have used the windows api a decent amount in rust before, so I can give it a shot, but I'm not home for the next few days.
Quickly looking at the lines of code you linked, I think overlapped.as_ptr() here is never null, but I can't check right now.

from pueue.

I submitted this PR now to the command-group crate. Pueue seems to work as expected on windows with this change!

from pueue.

Dependency is bumped and point release is published :)

from pueue.

You can check the daemon log by running pueued -d -vv.
The output on that terminal is that of the daemon.
It would be nice to get a bit more debug output, as I cannot see what the problem is from your description.

You might have to do some debugging yourself, as I no longer own a Windows machine.

I assume that this has something to do with the new way processes are handled in v3.0, but I'm not sure what could have caused this.

from pueue.

Thanks for the fast reply!
I just tested it on another windows pc, same error. pueued -d -vv only shows

10:28:19 [INFO] Checking path: "C:\\Users\\*\\AppData\\Roaming\\pueue\\pueue.yml"
10:28:19 [INFO] Found config file at: "C:\\Users\\*\\AppData\\Roaming\\pueue\\pueue.yml"
10:28:19 [INFO] Restoring state
10:28:53 [INFO] Didn't find pueue alias file at "C:\\Users\\*\\AppData\\Roaming\\pueue_aliases.yml".
10:28:53 [INFO] Started task: Start-Sleep -Seconds 1
10:28:54 [ERROR] Child 0 failed with io::Error: Os { code: 258, kind: TimedOut, message: "The wait operation timed out." }

I'm a bit busy the next 2 weeks, but once I find time I'll look into this more.
I like pueue a lot, it would be a shame if it didn't work on windows.

from pueue.

The error comes somewhere from inside this function.

Though I'm really not sure what the problem is. "The wait operation timed out" seems to be a super generic error for all kinds of windows process problems. Are you by any chance familiar with Rust and Windows systems programming?

This probably needs a bit of a deep dive and a proper debugging session by someone with a bit of experience.

from pueue.

A bit of context:

The error we see appears when pueued checks whether there're any finished tasks.

Over here we check if a child has finished via the try_wait call.
This call is usually expected to be successful, as anything else indicates that there's probably a problem while communicating with the system about the status of the process.

The error is then forwarded to the handle_finished_tasks function, where I luckily added some error handling code for this scenario.

Since v3.0.0, Pueue no longer uses the stdlib implementation of Child, but rather a wrapper around it via the command_group library.

The custom windows implementation for try_wait and wait can be found over here.

from pueue.

I checked out the windows docs now too and I think the following has been happening:

What I mentioned in my last comment should be correct, overlapped has type MaybeUninit<LPOVERLAPPED> and MaybeUninit::as_ptr returns *const LPOVERLAPPED, which is checked for being null, although we should be checking wether LPOVERLAPPED itself is null. We probably want to use MaybeUninit::assume_init instead, or just not use MaybeUninit at all: let overlapped = std::ptr::null_mut(); should be fine?
The error we get isn't really an error, but expected behavior when calling GetQueueCompletionStatus with timeout 0, because we aren't calling it to wait until a completion packet is send, we are calling it to check wether a completion packet has been send. But once the null check is fixed we won't be checking for the error anymore.

This is just what I came up with now, will test in a few days and make a PR if this was indeed the issue.

from pueue.

Awesome, thanks for the quick follow up!

I'll try to tackle the test suite refactoring soon, which will hopefully be a big step for running the tests on all supported platforms :)

from pueue.