[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