[Feature] Support windows service setup for pueued

[simonsan]

First, I was unsure if this would be a bug report or a feature request.

But as pueued says in the help text:

-d, --daemonize           If this flag is set, the daemon will start and fork itself into the
                          background. Closing the terminal won't kill the daemon any longer.
                          This should be avoided and rather be properly done using a service
                          manager

It should be easy to set up a service.

Describe the bug

Created Windows services time out, because (this is what I assume) pueued misses handling of Windows service events.

Steps to reproduce the bug

1. Trying to create a service on Windows 10. I did this the following way, which I found most easy within Powershell:

$params = @{
    Name = "pueued"
    BinaryPathName = "C:\Users\dailyuse\scoop\apps\pueue\current\pueued.exe"
    DisplayName = "Pueue Service"
    StartupType = "Automatic"
    Description = "Service to manage pueue task management tool"
}

New-Service @params

Et voilà, this should be it.

2. But when starting the service with Start-Service pueued it times out.
3. I assume that is because pueued doesn't handle the Windows service events.

Expected behaviour

pueued should be easy to set up as a service.

Logs/Output

Start-Service: Service 'Pueue Service (pueued)' cannot be started due to the following error: Cannot start service 'pueued' on computer '.'.

Which is most likely a related error to

Error 1053: The Service did not respond to the start or control request in a timely fashion

Because I see it timing out in services.msc.

Additional context

• Windows 10 Pro 21H2 19044.1865
• pueue 2.1.0

---

Useful crates

• Handling service events
• Interface towards working with service management platforms (for e.g., installing a service on first run)

[Nukesor]

This is most definitely because running pueued as a service in Windows environments hasn't been supported/thought off yet!

As I'm only owning a Linux machine, I rely on the community to implement Windows/Mac specific logic and find such issues :)

It would be great, if you could take a look on how to implement this! Especially since you seem to be quite knowleadable about this topic and already did some research on how to do this :).

[simonsan]

I'm less active on my PC in summer, I might take this as a winter project then! If I didn't come up with something until November, feel free to ping me! Cheers!

[AntoniosBarotsis]

I'm not sure if this is something different but I've been using pueued & to make this work on powershell. Does that work for you?

[Nukesor]

I think the idea is to, for instance, start pueued on startup as a windows system/user service.

The same is achieved via a systemd user service on linux systems that run systemd.

[simonsan]

Huhu, I'm in the middle of some other project and won't be able to work on it anytime soon. If someone feels like doing this, feel free. I have it still in mind, but just can't right now. Cheers <3

[AntoniosBarotsis]

I'm not too sure if this fits your needs but could you for instance use something like Task scheduler?

There's a way for you to define a task to run on-boot by making a simple XML file (see here). There's a few other ways listed but this seems to be the easiest.

[kitzbergerg]

You can do the following on Windows:

Press Windows+R and type shell:startup. Create pueue-service.vbs with content

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run chr(34) & "pueued" & Chr(34), 0
Set WshShell = Nothing

Disclaimer: I have no idea about vbs, the script is just something I copied from somewhere.

[papanito]

You can also add a shortcut into %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup and target= path-to-pueued -vv

Sure this will open a command line window in the foreground, but you can start it minimized.

Not ideal but works for me.

[papanito]

I'm not sure if this is something different but I've been using pueued & to make this work on powershell. Does that work for you?

adding & just immediately returns The service did not respond to the start or control request in a timely fashion.

[YDX-2147483647]

Hi! As this issue has been opened for a while, I add a section in https://github.com/Nukesor/pueue/wiki/Common-Pitfalls-and-Debugging. If anyone resolves #344 or #442, please consider update the wiki.

Windows quirks

Due design differences between Windows and Linux, pueued --daemonize may not work as expected on Windows, including but not limited to the following quirks.

• The daemon may still exit if you close the terminal.
• If pueue follow in the same shell where pueued is spawned, then Ctrl+C may also shut down the daemon.

There are discussions / workarounds in #344, and implementation is welcomed.

[melMass]

I was about to open a similar issue to add this info to the quickstart guide.

This is the path I tried (mostly to give more info to Nukesor):

NONE OF THESE ARE WORKING

Using a windows service

• Create a service:

  gsudo sc.exe create "Pueue Daemon" binPath= "C:/Users/User/.cargo/bin/pueued.exe"

  (instead of gsudo you can just open a terminal with admin rights)

• Setup the service start option:

  gsudo sc config "Pueue Daemon" start= auto
  gsudo sc start "Pueue Daemon" 

• Upon start you will get a service timeout (1053), you can try to pass -d to the flag which will still error out but actually spawn the daemon, BUT the client will fail to connect because of TLS:

  Error: Failed to initialize client.
  
  Caused by:
      0: Failed to initialize stream.
      1: Failed to initialize tls invalid peer certificate: BadSignature.

  more info here: invalid peer certificate: BadSignature with Cloudflare WARP denoland/deno#21169 & Support for ecdsaWithSHA512 signature algorithm rustls/rustls#1367

Using Shawl

• Install shawl and the service and run it:

  cargo install --locked shawl
  gsudo shawl add --name pueue_daemon -- C:/Users/User/.cargo/bin/pueued.exe
  gsudo sc start pueue_daemon

  This removes the timeout error and the service now run fine but we have the same TLS issue on the client.

---

If I get this right the solution would be to have a custom main on windows following this signature: fn(argc: u32, argv: *mut *mut u16) for instance using windows-service-rs

[graphixillusion]

Is there any news about this?

[Nukesor]

Nope, to my knowledge, nobody started working on this.

[MolotovCherry]

I don't have time to implement this right now, but I just wanted to drop in for others and say that I might be interested in solving this, this is fairly trivial to do internally using the windows-service crate. The service itself could be built into the pueued command on windows.

This most certainly would solve all the bugs in one fell swoop.

The actual implementation of the service is not difficult at all actually. It doesn't even require a custom main. When the service starts, we start the daemon's event loop, and when the service requests stop, we kill the program. Nice and easy. 😄

Edit: Ahhh, my bad, it seems this was already mentioned! 😅

---

In any case, Nukesor, the implementation would be similar to this:

On Windows there are 2 extra flags

• --install flag installs the windows service*
• --uninstall flag uninstalls the windows service
• -d/--daemonize flag gets run by the windows service. This flag cannot be used by the end user, only the service. If this is undesired behavior, we will require an extra flag specifically for the service, such as --service. We could make this flag hidden from the help so it's transparent

* When the service is installed, you cannot move the pueued binary anywhere else. It must stay at the same location always. If someone wants to move it, they should first uninstall the service, move it somewhere else, and reinstall the service.

Thoughts?

It definitely wasn't the fact that my daemon quit for no reason after I followed a task that got me to find this issue 😏

Edit: It might be possible to just hack this process with process creation flags to stop it from quitting on us too. But I still think the service approach is the proper one.

[Nukesor]

Hmm.

In general, I would like Pueue to be integrated into the native OS's service system.
Changing the -d behavior would:

• force all windows users to always use windows' native system service
• Be a pretty hefty breaking change, as it would break currently existing "daemon" setups.

So I would go for the --service flag. This would allow for a clean introduction of this feature without any backwards incompatible changes :)

Thanks for the research, much appreciated. Maybe we'll finally be able to close this ticket after a few years :D

[MolotovCherry]

In general, I would like Pueue to be integrated into the native OS's service system.
Thanks for the research, much appreciated. Maybe we'll finally be able to close this ticket after a few years :D

Actually, despite how this looks, it is actually trivial to do. It this will be pretty easy for me to knock out in a few hours 😄 I have a vested interest in seeing this get fixed since it annoyed me lol, so I'm just gonna PR this.

So I would go for the --service flag. This would allow for a clean introduction of this feature without any backwards incompatible changes :)

Got it. I'll do it this way then. Would you like the flag hidden or shown in the help with appropriate description? It's internal anyways, so hiding it has no downsides.

[Nukesor]

I would go ahead and show the flag with a appropriate description. As long as it's clear from the description that it shouldn't be consumed by the user, I'm fine with it being visible :)

[MolotovCherry]

The windows service is done now and works great (see #567). I would appreciate it if others would do some testing however, just as a final check.

[Nukesor]

Will review soonish :) Currently on holiday for the next two weeks ^^

[simonsan]

Wow, @MolotovCherry thank you so much for taking care of this. And have a great, enjoyable and recovering holiday @Nukesor! :)

[Nukesor]

Implemented by @MolotovCherry in #567 :)

This will be in the 4.0 release. That release still needs a bit of work, but it's on the horizon :D