Kaseya Community

How to purposfully fail a script

  • What are some scripting methods used to abort a running script so that it fails?

    I've tried compiling an executable that returns 1 or -1 and using the "execute file, wait for completion" method, but the scripting engine doesn't seem to check the return value of the executable. I've also tried programs that output to stderr and throwing unhandled exceptions, but all do not trigger a failure for the script that executes it.

    Legacy Forum Name: How to purposfully fail a script,
    Legacy Posted By Username: Zestysoft
  • I think a Get File for a file that doesn't exist will fail a script.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: sequoya
  • If you try to execute the same script from within the script, it will fail. Example:

    Script Name: Check for Exchange
    Script Description:

    IF Service is Running
    Parameter 1 : MSExchangeIS
    THEN
    Write Script Log Entry
    Parameter 1 : Exchange is Installed
    OS Type : 0
    ELSE
    Execute Script
    Parameter 1 : Check for Exchange (NOTE: Script reference is NOT imported. Correct manually in script editor.
    Parameter 2 :
    Parameter 3 : 0
    OS Type : 0

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: billmccl
  • I read in one of the Kaseya KB articles or similar that using Pause Script and setting the value to 0 (or was it leave it blank?) would automatically fail a script.

    Whichever value it was the article specifically mentioned it as a way to intentionally fail a script.

    Hope this helps.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: SteveWebster
  • SteveWebster
    I read in one of the Kaseya KB articles or similar that using Pause Script and setting the value to 0 (or was it leave it blank?) would automatically fail a script.

    Whichever value it was the article specifically mentioned it as a way to intentionally fail a script.

    Hope this helps.


    Pause a script, and don't enter a value. That'll cause the script to report as failed in that step.

    Andrew

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: andrew.doull@computer-care.com.au
  • Easiest way I know is to test a registry key that does not exist. This is how I create accurate views for applications installed on my servers.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: boostmr2
  • [QUOTE=andrew.doull@computer-care.com.au;48975]Pause a script, and don't enter a value. That'll cause the script to report as failed in that step.

    Andrew[/QUOTE]

    I concur Pause is the easiest. If you are trying see if a script worked though a cleaner way would be to make a sub script/s that will run if certain conditions apply as failed scripts will give you false alerts...

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: HardKn0X
  • Ah, but isn't the point that you can set views based on whether a given script failed or not?

    So you can either:
    1. Write the script to detect, say, Exchange, and have it "fail if present"
    2. Write the script to detect, say, Exchange, and have it run the "Exchange is Present" script

    Then:
    1. Set up a view called "Exchange Servers" that shows all servers where "Exchange Detect" failed THEN
    2. Set up a view called "Exchange Servers" that shows all servers where "Exchange is Present" ran.

    I guess it's just to save having to write the second script... right everyone?

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: Matthew Bartels
  • I'm really not sure why someone would want a script to fail.

    the if statement should carry it all so what if you need to write 2 or three scripts to get it done (although I cant wait for nested ifs =D)

    heres my thought process...

    script success either "then" or "else" has fired leading to some kind of log or additional script to run or something

    script failure, neither "then" nor "else" has fired producing a useless script. or at the very least a failure in the script log.

    I hope that the original poster comes back to read this.

    My questions to you are:
    What is it that you want to accomplish?
    What is the purpose of wanting to fail the script?

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: thirteentwenty
  • thirteentwenty
    I'm really not sure why someone would want a script to fail.

    My questions to you are:
    What is it that you want to accomplish?
    What is the purpose of wanting to fail the script?


    The main reason from my point of view is that I don't know whether I have to check the script log if a script has succeeded, but I know for sure I do if a script comes back as having failed.

    Andrew

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: andrew.doull@computer-care.com.au
  • [QUOTE=andrew.doull@computer-care.com.au;49109]The main reason from my point of view is that I don't know whether I have to check the script log if a script has succeeded, but I know for sure I do if a script comes back as having failed.

    Andrew[/QUOTE]

    Still makes little sense to me, it the script fails neither the THEN nor the ELSE portions will have happened. So your desired outcome will not happen... so if you're deploying a bit of software you'll most likely want to run an audit after its done, if its not there... the script failed.

    Or you could do it the easy way and set up your agent monitor to create an alert/create ticket/alarm/email on script failure...

    Monitor Tab |> Agent Monitoring > Alerts > select "Script Failure" from the pull down.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: thirteentwenty
  • thirteentwenty
    Still makes little sense to me, it the script fails neither the THEN nor the ELSE portions will have happened. So your desired outcome will not happen... so if you're deploying a bit of software you'll most likely want to run an audit after its done, if its not there... the script failed.

    Or you could do it the easy way and set up your agent monitor to create an alert/create ticket/alarm/email on script failure...

    Monitor Tab |> Agent Monitoring > Alerts > select "Script Failure" from the pull down.


    Usually the script failed step will be the last step under a THEN or ELSE branch.

    e.g.

    If computer is set up correctly
    THEN
    Do work
    ELSE
    Write explanation of what needs to be changed to script log
    Script fails


    Andrew

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: andrew.doull@computer-care.com.au
  • If that is the scenerio that you're working with, why not something like this
    inline edits in ALL CAPS

    If NOT computer is set up correctly
    THEN
    Write explanation of what needs to be changed to script log
    ELSE
    DO SOMETHING


    then generate an automated report based off of this script log and have it emailed to you on a regular basis.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: thirteentwenty
  • thirteentwenty
    I'm really not sure why someone would want a script to fail.

    the if statement should carry it all so what if you need to write 2 or three scripts to get it done (although I cant wait for nested ifs =D)

    heres my thought process...

    script success either "then" or "else" has fired leading to some kind of log or additional script to run or something

    script failure, neither "then" nor "else" has fired producing a useless script. or at the very least a failure in the script log.

    I hope that the original poster comes back to read this.

    My questions to you are:
    What is it that you want to accomplish?
    What is the purpose of wanting to fail the script?


    Thirteentwenty,

    My question came up while kicking the tires of the scripting engine. I had assumed that executing something like a shell script or executable and having either return something non-zero would cause the fail flag to raise, but it didn't. I began to wonder when one needed to use "Continue script if step fails" (btw, I didn't see use of this option as a possibility in the "script failure" though process?).

    The programmer in me has learned that it's safer to fail immediately upon un-handled error then to blindly execute everything to completion. Once a failure occurs the script is working off of false assertions and unknown (perhaps destructive) events can happen.

    By explicitly failing a script it's also easier for me to be able to tell why (since the where is given) it failed and re-write something more robust to handle that failure in the future. Auditing IMHO duplicates work that the script should have already accomplished, and it also means I'll need to maintain my work in two separate places leading to a possible out-of-sync situation.

    Lets say I have two incompatible versions of a program. I'm interested in uninstalling the older version first and then installing the new one. I want to guarantee that the installation of the new one does not occur if the old one does not completely uninstall itself successfully. As it stands now, I may do something like execute msiexec /x xxxxxxx and it may fail, but the script will show "success". If I understand your solution, I should write another script and have it called after my call to msiexec and have it do some type of sanity check. The problem with this is that I'd have to know everything that the uninstaller does in order to fully check that the uninstall process worked.

    Of course my example isn't limited to just install/uninstall... I would want my script to fail if ANY executable returned a non-zero value. Envisioning having a second audit script for every executable call seems like a painful endeavor!

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: Zestysoft
  • Zesty,



    The "Continue on Fail" still boggles me a bit too, but there are times I suppose when one would use it. I've seen it in a few examples of scripts posted here...



    I've often wonderd how Kaseya know when a script fails, as there are other variables that could cause similar conditions... a command taking forever to run because the machine is bogged down with other stuff...



    By telling the script to fail you are in a sense not allowing the script to succeed. In your example of "I may do something like execute msiexec /x xxxxxxx and it may fail, but the script will show "success"". The script is successful, now wait, before the eyes roll to far back let me explain. In this case the script is just to fire a msiexec command which it does. the script does not look to see if that command was proccessed correctly or if it actually worked. So in a sence you didn't really script the uninstall of an application, just a way to fire the command in an unattended manner.



    When I do this (keeping with your example, it's a good in my opine) I'll drop in the switches to log and have another script look for a success or fail at that point. Again, this is just because I've scripted an unattended uninstall command. The log will tell me if it worked or not, and that will (read: should) let me know if the command is successful. (for the record I pipe out log files for all of my msiexec commands, thats just habbit because really dont like msiexecs ability to hide during install.)



    Now I do agree with you that auditing every script like this is, in your words, "a painful endeavor", I would use something a bit more graphic and crude. But the audit would only be for testing only, once you've tested and come back successful, there is no longer a need for the audit. Yes there are those rare cases that fall outside of the test box but, those are rare and can be dealt with .



    I think, for me, one of the biggest things that I had to deal with is that we are just scripting. Not programming. Once I got over that I had to realize what I was scripting. Then it got a bit easier... OK, it got a bit tougher, because of a few extra steps involved with getting it right, but when it comes to actually deploying on a large scale, you'll see find a higher success rate in your outcomes.



    Now that all of that was said, a recap for those (like me sometimes) who may have misinterpreted what I was saying.



    My confusion is: I don't see the need to cause a script to fail, I could go into this with more detail, but I don't see the need.



    My view is: We have to remember what we are scripting, the example above (which is a really good one btw) is the (un)install of an application. I say that we are just scripting the actual commands that do it. If the command itself does not produce an error it is successful. Now the outcome of that command is different.



    So I'm sorry, until I can see a better reason for failing a script before it is done, this is the way I'll see it.



    Again I like the example you used because it perfectly illustrates both sides of the coin on this one.



    in Andrews post he states that "Usually the script failed step will be the last step under a THEN or ELSE branch"



    By the buy Andrew I'm not trying to pick on your anything, just trying to better understand this.



    In my mind this is what is being said.

    the IF condition has been met

    THEN branch starts, then fails because ???, even if all steps are done successfully the script still failed and this will be reflected in the script log



    the IF condition is not met

    ELSE branch starts, same result as above.



    IMO this will make it alot more difficult to find out when a script has truely failed (which can easily be troubleshot and fixed) because you will never have a scripting success.



    Also I'd like to fix something while I'm at it

    I said



    script failure, neither "then" nor "else" has fired producing a useless script. or at the very least a failure in the script log.



    It should read

    script failure, either the "THEN" or "ELSE" has not completed

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: thirteentwenty