Auto-launching & electron as a Windows service


#1

Hi!

Quick questions for the electron team regarding auto-launching! :rocket:

Setup:

auto-launch: ^5.0.5
electron: ^2.0.17
platform:

  • Windows 7 x64
  • Windows 8 x64
  • Windows 8.1 x64
  • Windows 10 x64

Context:

I’ve been using auto-launch in production, and I have noticed that auto-launch doesn’t reliably relaunch application when the computer restarts. Locally, on my computer it restarts fine, but on our clients’ servers, it doesn’t necessarily reboots every time. This is problematic because our app is a service app that establishes the link between our clients’ servers and our cloud infrastructure to offer them analytics on their latest data.

Let’s take a case in point. One of our client’s server restarts daily. Some days the application boots, some others it doesn’t. On the days that the application is down, it does not output any logs. My assumption is that the application simply doesn’t start. It is really hard to test and debug because not only do I not have control over the server, but I have no idea how to test the functionality.

Hence,

Questions:

• Do you have any idea of how I can test for auto-launch?
• Does auto-launch only kick in when the user on which the app is installed logs in?
=> If so, is it possible to make auto-launch launch automatically whether or not the user logs in?
• I’ll be deploying a newer version of electron in the next release (electron 4.0.5). I’m considering switching to the setLoginItemSettings API. Similarly to the previous question, does setLoginItemSettings only kicks in when the user on which the app is installed logs in? If so, is it possible to make the app launch automatically on computer boot rather than user logging?
• If we assume that the platform is always going to be Windows 7+, is there a manual way to setup the app to boot at server boot? Something like modifying registry keys or creating a service/window’s cron-equivalent?

Thanks a lot for your answer, you are all lifesavers :rainbow::unicorn::sunny:

Have a great evening :rocket:

Phil


#2

Hey man

We have the same problem on our side.
Our best robust solution was to set the app’s auto launch in 2 different ways.

  1. With the “auto-launch” module which sets the app to start via registry startup.
  2. With squirrel we create a shortcut in the startup folder. (Lookup how to create shortcuts for your app with squirrel and electron - use the “–shortcut-locations” argument with a value “Startup”)

This causes a bad side effect - on computers that both the registry and startup folder succeed (most computers) the app will start twice on the system’s startup.
We anyway use the requestSingleInstanceLock API to verify only 1 app is running at all times so it solved our issue.


#3

It could also be a solution to write an external startup script (if you’re running this on servers, they likely have Python installed, or you might be able to do it in a batch script) that first checks to see if the app has started, then starts it if it hasn’t. You could even track the app’s status with an environment variable to make sure that the script doesn’t get run twice before the much slower Electron gets its butt in gear. Or your main process could check for other instances running before it ever opens a window, in which case the user wouldn’t see anything amiss even when your app runs twice.


#4

Hey gillib,

Thanks for sharing your trick! On our side, we are investigating a different approach for deploying the app as a windows service.

What our research seems to suggest is that the Electron ecosystem does not provide a way for electron apps to be booted at computer start rather than at session login. Instead, we are currently investigating how to transform our app into a Windows service that can be automatically started on computer boot. The problem with Windows services is that since Windows Vista, services are no longer allowed to have a UI. Hence here is our tentative solution:

  • Separate the presentation tier from the logic & data tier by limiting the electron app to the presentation tier and moving the logic & data tier to a headless Node.js application. This effectively means that we need to package a compiled version of the Node.js runtime with the application as part of the app.asar.unpacked folder, alongside the bundled javascript.
  • Implement Auto-Launch or setLoginItemSettings API within the electron app for launching the UI whenever a user logs in.
  • Wrap the Node.js application with the Non-Sucking Service Manager (https://nssm.cc) for Windows, and make the Node.js application a service. The Electron application becomes responsible for running the commands that will do the initial configuration and launch the Node.js service. This will require however that you use something like sudo-prompt to be able to gain privileged access.

This is by no means a complete solution, and comes with it’s own drawbacks like how to ensure that the service can be run/updated by any user, or automatically.

If you find anything let me know :slight_smile:


#5

Hey this is an interesting solution. For us it might be problematic since our clients might not want us to install a service as it sounds and feels more intimidating to their IT personnel.
We will definitely think about it.

I have a question though about you approach -
What is the difference between setLoginItemSettings and auto-launch??


#6

I read the code,and found out that it is exactly like the auto-launch module…
Both of them setup the auto start of the app in the registry


#7

Did you see anything that could seem to start the app on computer boot rather than on user logging?

On our side we’ll be working on this issue next week - until then stay posted :wink:


#8

Hey @gillib

We’ll be postponing that feature for a while - the startup priorities are always a changing thing :wink:

I’ll let you know as soon as I get started on this task - might take a few weeks before I do though.

In the meantime, feel free to share your insights :slight_smile:

Have a great day :rocket:

Cheers,

Phil