Vision Client - Option to launch Vision Client silently? (Ignition Edge)

I was wondering if there is a way to launch the vision client silently?
I have a system set to automatically launch my Ignition Edge Vision project automatically. When it does this, the launcher dialog pops up. During this time, a user could intercept this and close out the dialog while the gateway boots up (on my system, it takes about 45 seconds).

I need to prevent the ability for a user to interrupt this startup process.


I make the display manager service depend on the Ignition service. That way the autologin and custom Xsession in the display manager lead directly to a runnable Vision client.


Can you point me in the right direction on where to make that dependency?
I'm using LightDM as the display manger on my Linux box. I have the LightDM.conf file configured to autologin with the user account in question.

Once the user logs in, I have an autostart script run Vision upon the user logging in.

Is still a way to silently launch in the event this still has a large (or large enough enough) delay to startup?

You use an override for lightdm's systemd service that looks like this:


{ Adjust service name to suit your situation. }

Then lightdm simply won't start the login manager until after Ignition itself has started, and therefore won't do your auto-login before Ignition is running.

1 Like

Thanks. I tried this and some other things. The issue here is that what the Linux system sees as the Ignition Gateway service status not not equal what Ignition sees. What I mean by this is if I query:

systemctl list-units --type=service

And look for Ignition-Gateway, systemctl shows this as RUNNING even though from the standpoint of Ignition (via gwcmd) the Gateway is still starting and the client cannot connect.

I managed to do a highly customized workaround that works for my specific requirements. Maybe this works for others. Here is what I ended up doing:


  • The Linux based PC hosts Ignition Edge Gateway and also hosts the Panel module, where I am loading a Vision Client to a panel touchscreen.
  • The PC auto logs-in into a restricted desktop environment (OpenBox) meant for use by an operator (which took other customization effort!).
  • The client takes time to launch while it waits for the Gateway to initialize, which opens up the opportunity for the user to interrupt the Client launcher. This is being used in a remote application where there is no engineering staff to come fix something if the user does something wrong, so this risk is high.
  • Putting in a "sleep" script during the XSession login results in a "blank" screen while the script waits, so this is not an ideal solution as I imagine this can cause operator confusion.

Auto-launch the Vision Client project WITHOUT allowing the user to interrupt the process

I created an autostart script to run once the user logs into the desktop environment (in my case, OpenBox). This autostart script does the following:

  • Disables all user input (via xinput).
    Note: this requires modifications to give the user permissions to use xinput command, or at least
    a specific script
  • Launches the Vision Client
  • Queries gwcmd -i and checks to see if Ignition Service thinks it is running.
  • Once running, there is an additional delay to allow the Vision Client to boot into the project
  • Re-enables all inputs, as the Vision Client should be loaded.
    NOTE There does not seem to be an easy way to query the status of the Vision Client loading
    process so I opted for a straight timer here (which may vary from system to system).

The Gory Details
Here is the autostart script I used. Milage may vary.

#disable user inputs
sudo /usr/local/bin/ &

#Launch Vision Client project
sh -c '"/path/to/client/launcher/app/" app.home="/home/username/.ignition/clientlauncher-data" application="PROJECT NAME HERE" &' &

#Check the Gateway Service
while ! sudo /path/to/Ignition/Gateway/ -i | grep -q 'Gateway Status: RUNNING'; do
  sleep 5

#Wait for Client to fully load 
sleep 10

#Re-enable inputs
sudo /usr/local/bin/

The user in question was granted sudo rights specifically to the Disable and Enable Input scripts by modifying the sudoers file(via visudo). I also had to give access to gwcmd.

operator ALL=(ALL) NOPASSWD: /usr/local/bin/
operator ALL=(ALL) NOPASSWD: /usr/local/bin/
operator ALL=(ALL) NOPASSWD: /path/to/Ignition/Gateway/

Here are the commands inside the enable and disable inputs script:

xinput list --id-only | xargs -I {} xinput disable {}
xinput list --id-only | xargs -I {} xinput enable {}