Showing results for 
Search instead for 
Did you mean: 

Apply State via Systemlink

I have not used states too much as I have been mostly creating our own feeds and have the clients point to it.   But it is a little unwieldy to maintain as you can add to a package repo via the interface from   Select a LV 2019 SP1 (thought the search box does not return anything when you type LabVIEW, anyone else notice that?) and download from and it adds the packages....  


Anyway so I decided to try and use Apply state...  Install all the tools needed and then create a state.   This way all the packages/feeds are nicely bundled.


But I have noticed that when I install the SL Client...  Connect it to the server... And say apply state...  The first thing it does is to disable the SL client service so the client is disconnected.  The client says it is applying the state but it just sits there.  And the client never connects again.  If the applied state has a client that is older than the current installed version.  Does this cause a bootstrap type of issue?  Since the State has SL 20.1 and installed is SL smart enough to handle this?

0 Kudos
Message 1 of 9

What is the SL version of the systems you are applying the state?

Is the state containing the "ni-systemlink-client" package? If yes, what exactly version?

0 Kudos
Message 2 of 9

Sure.  The state contains:

The client local had the 2020 R4.  Let me get that package number from the installer.



So what I noticed is that the local PC after applied state did not ever reconnect to Systemlinker server.  But the SL client 2020 R4 was uninstalled and the R3 version was available to be installed.


After I installed the R3 version of the client and applied the state it worked as expected.   So it does seem that when downgrading systemlink via a state that at least in this case failed and required a local manipulation to get the state applied.


So are people removing the SL client from their states to avoid this?   I will try on another system and report.

0 Kudos
Message 3 of 9

On a fresh system same the applied state does not automatically apply.  Will try a third system starting with a the same version of Systemlink client 2020 R3 as the applied state to see if it automatically applies the state with intervention.  I suspect it will.  So seems like to be safe it is best to pull the ni-systemlink-client package out of a state to make sure that whatever version of SL client is installed that the state will be applied.

0 Kudos
Message 4 of 9

Actually no.  I installed client R3 and was the same.  I stripped out all systemlink client and salt minion services...basically every package that is installed by the client installer.  And the client still disconnected when applying the state.  I have to remove and re-approve the client to the server to get connection back after state being applied.

0 Kudos
Message 5 of 9

I was expecting that you were actually downgrading SystemLink Client through the state.


Here is how things work right now:

1. We don't support downgrades on the SystemLink Client. If you downgrade the SL Client package then its configuration will be lost. This includes the server on which to connect too and the keys of the client. By removing these, the server will not know anymore who this client is when it tries to reconnect. 

2. These SL Client related packages have also dependencies and when these dependencies are downgraded, then SL Client will get downgraded as well. I am pretty sure that you were in this use case on the last try when you expected to work. An example of these packages would be the "ni-sysapi" (NI SystemAPI Framework) which is getting pulled by many other NI products, so this package could be the one that triggers the downgrade of the SL Client.


At this point, if you cannot build your golden state from scratch then you have to create it from a golden system and polish it until it doesn't trigger a SystemLink Client downgrade.


If you are still encountering weird behaviors, please send us the state and the client snapshots to take a look over them. 

Message 6 of 9

I am starting to understand your pov but this implies that older states have little utility without being scrubbed for these dependencies that cause a disconnection.   Seems like something the tool should handle as this will be a known use case.  Namely, applying a labview 2017 SP1 state and test an old test case for example.  The expectation is that I should be able to apply a state successfully of any vintage.


You are right that I can create a new state that is current every time we upgrade...  But this really only applies to the current latest image not legacy states.

So if I get a list of all the recursive dependent packages from the ni-systemlink-client and remove these from the states then the state should be client agnostic?


Seems like the SL client is needs to be decoupled from the state by the tool when making the state.  I do not see the utility of saving those packages if by saving them it causes the client to disconnect permanently from the server when the state is applied.