Skip to main content
commvault.com commvault.com

Hi All,

 

Qscript in the link here started to fail randomly since yesterday for me..in both of our commcells..

Could not understand why I have this issue, for fun sake I tried to copy paste from CV’s documentation, from -help section of qcommand - maybe after 5 months of succesfull everyday use somehow script decided for himself to mistype the command...lol - laughing through tears here when example in -help section in itself is faulty :)

 



Same goes for API call, response code is ‘200’ - but in the response is one of CV generic resp codes, which is ‘2’.

 

    def get_commvault_clients(self):
        """This method returns all servers with backups in past 24 hours from DK1 and DK2 commcells"""

        job_history = j]
        for api in self.api_url:
            jobs_request = api_"url"] + "ExecuteQCommand"
            jobs_response = requests.post(
                jobs_request,
                headers=api "headers"],
                timeout=3600,
                data="command=qoperation execscript -sn QS_DataProtectionJobSummary -si @LastNDays='2'"
            )

            if jobs_response.status_code == 200:
                jobs = jobs_response.json()
                for i in jobs "ExecScriptOutput"]S"FieldValue"]:
                    details = {...}

 

@Benjis , thanks for the post and the screenshots.  I’ll get some internal folks to look into this.

For context, you said it started failing a few days ago…..when did it work last?  Did you make any changes to the environment in between that time (thinking mostly about upgrading the Commserve)?

Hi Benjis,

 

 Try running as follows:

 

Going to assume your Commserve updated recently, looks like the syntax changed between SP20 and SP21:

 

https://documentation.commvault.com/commvault/v11/article?p=features/cli/qscripts/CommServ.QS_DataProtectionJobSummary.Readme.html

 

https://documentation.commvault.com/11.21/expert/DataProtectionJobSummary.html

 

 Please confirm :)

 

Vance Sicherman

Commvault Support

Hi @Mike Struening, @Vsicherman 

We did not in fact have any upgrades in the past few days, nothing actually changed in the environment..

I’ve tested this qscript with timeframe instead of a specific day count - that worked, I’ve also tested this qscript without any parameter for date or timeframe - also worked.

But just when you want to use parameter ‘LastNDays’ - it fails..I have a support ticket opened for this as well.. :) 


Also I do not see the changes in syntaxt from SP20, to SP21:

SP20: qoperation execscript -sn QS_DataProtectionJobSummary -si @LastNDays = '7'
SP21: qoperation execscript -sn QS_DataProtectionJobSummary -si @LastNDays = '1'

@Benjis , can you share the case number?  I definitely want to track this one.

@Mike Struening case number is 210804-166 :)

@Mike Struening @Vsicherman 

 

Got on a call with support and then remembered that on some previous cases I had to delete qsessions.userID file from installation path folder…That actually solved the problem. Now, qlogin/qlogout operations or timeout of qsdk maybe was not deleting that file as it should or there was any other failure with that qsession file.

I’ve asked support engineer to go to development with this to get RCA/root cause for this, as to manually delete those files when in logs there was nothing said about any qsdk stuck/expired session is not nice :|

 

Thanks for the follow up!  Curious to see what development says about your (very valid) points!

Hi Benjis,

 

Regarding this one, I noticed the error you were getting was when running manually from powershell, the command you would need to get this working in powershell manually would be:

qoperation execscript -sn QS_DataProtectionJobSummary -si "@LastNDays='7'"

Leaving it as per below or any combination without including the whole parameter in double quotations:

qoperation execscript -sn QS_DataProtectionJobSummary -si @LastNDays='7'

results in that error in qcommand log:

“Conversion failed when converting date and/or time from character string.”

I am not suggesting that the automated version needs any change if it was working in the past and started working after you deleted the qsession file so would be interesting to find out more here.

By any chance had you backed up the qsession.userid file before you deleted it? This would be useful to provide on the open support case if you were going after RCA and deleting that file resolved the issue. If you have a copy of the file before deleting it please definitely upload it to the support case.

Hey @Benjis , I notice that the incident was closed without an RCA.  Would you be able to leave the requested debug keys in place until it reoccurs?

I have messaged the case owner requesting they reactivate and reach out to you as well.

Hi @Mike Struening,

thanks for doing so. I can keep the debug options, but I really do not know when this issue can occur 🙂 I suppose completely randomly.

 

Ben

Of course!  Without an RCA, there’s no real solution.  At least with the debug in place, you’ll be able to provide the logging to help dev get to the bottom of things.  I’ll keep an eye out for any updates as well.

Marking the above answer as correct since the case created has been closed since there has not been a reoccurrence (by all means, update this thread if that changes!).

Reply


Terms & ConditionsCookie settings