I have a problem with a hang using xp_cmdshell.
The executable is called, performs its work, and exits. It is not hanging because of a ui prompt in the exe. The exe is not hanging at all. The exe disappears from the process list in task manager, and internal logging from the exe confirms that it executed the very last line in the main function
the call to xp_cmdshell does NOT return control in SQL. It hangs on that line (it is the last line of the batch). Killing the process is ineffective. It actually requires a restart of sql server to get rid of the hung process (ugh)
The hang only happens the first time it is run. Subsequent calls to the procedure with identical parameters work and exit correctly so long as the first one is hung. Once SQL is restarted, the first subsequent call will hang again.
If it makes any difference, I am trying to receive the return value from the exe -- my sql procedure ends with:
exec #i = xp_cmdshell #cmd;
return #i;
Activity Monitor is reporting the process to be stuck on a wait type of PREEMPTIVE_OS_PROCESSOPS (what the other developer saw) or PREEMPTIVE_OS_PIPEOPS (what I'm seeing on my current testing)
Any ideas?
Just came across this situation myself where I've run an invalid comment via xp_cmdshell.
I managed to kill it without restarting SQL, what I've done was to identify the process that run the command and kill it from Task Manager.
Assume your SQL was running in Windows 2008 upward:
Under Task Manager, Processes tab. I enabled the column to show Command Line of each process (e.g.: View -> Select Columns..).
If you unsure what command you've run via xp_cmdshell, dbcc inputbuffer(SPID) should give you a clue.
We had the same issue, with SQL Server 2008, also with calls involving xp_cmdshell and BCP. Killing the sql process ID didn't help, it would just stay stuck in "KILLED/ROLLBACK" status.
Only way to kill it was to kill the bcp.exe process in Windows task manager.
In the end we traced the issue down to wrong SQL in sproc that was calling the xp_cmdshell. It was by mistake opening multiple transactions in a loop and not closing them. After BEGIN/COMMIT trans issues were fixed, PREEMPTIVE_OS_PROCESSOPS never came back again.
We actually did eventually figure out the problem here. The app being called was used to automatically dump some documents to a printer when certain conditions happened.
It turns out that a particular print driver popped up a weird little window in the notification tray on a print job. So it was hanging because of a ui window popping up -- but our app was exiting properly because it wasn't our window, it was a window triggered by the print driver.
That driver included an option to turn off that display window. Our problem went away when that option was set.
Related
I am receiving the following error in SSIS "An OLE DB error has occurred. Error code: 0x80004005" for each of my data flow tasks.
When I set 'delay validation' to 'True' for all data flow tasks and execute my packages the integration works okay.
However the SQL agent job doesn't run.
As far as I can tell, the reason for this is due to the 'to_update' temporary tables I have set up to act as a middle man. The Microsoft article below seems to back this up.
https://support.microsoft.com/en-us/topic/error-message-when-an-ssis-package-runs-that-is-scheduled-to-run-as-a-sql-server-agent-job-an-ole-db-error-has-occurred-error-code-0x80004005-6a687a1f-917a-d3ae-4d3a-44e7dae82988
As the article says my next step would be to 'change the permissions for the Temp directory of the SQL Server Agent Service startup account. Grant the Read permission and the Write permission to the SQL Server 2005 Agent proxy account for this directory.' however I honestly have no idea where I would do this (I'm new to the world of SSIS!)
If someone could point me in the right direction that would be much appreciated.
There are a few things to take into account, the delay validation might be a red herring and nothing to do with the error or it might be that the Agent is calling an older version of the package that doesn't delay validation. So first of all make sure the package with the delay validation is deployed correctly and it is the one being run by SQL Agent.
Then, if the problem continues it could be permission or that the Temp directory is running out of space, worth checking it.
Finally, if it comes to permission problems then whoever is in charge of maintaining the DB, I'm assuming there is a DBA, should check what account is running the package from SQL Agent and make sure it has the right permissions.
another thing to check:
make sure the Run as is correct and if not running as 32 bit try it or viceversa.
After spending some more time it looked like the issue was actually related to disk space, the memory on the server I was using was running at 100% and the SQL agent jobs were running but very slowly and never actually ran successfully. I ended several processes and staggered when each of the SQL jobs run so they do not all trigger at once, and these are running successfully again.
We've got a lot of Access databases (typically 2007) and we find this with nearly all of them as of recently. When a user launches a database it works perfectly fine until they close it down, any subsquent launches give an error on startup...
Execution of this application has stopped due to a run-time error
Users are using Access Runtime and I have access to the full version for legacy development purposes. One thing we have found is that after the first launch there's a hanging MSACCESS.exe process, if you bin it off then it fixes Access temporarily.
We have attempted compacting the databases to no avail.
Is there anyway to get a more detailed error? I have checked event viewer and also set the startup form to none, yet the issue still occurs.
Open one of the offending database and watch when the error kicks in.
That should lead to either an error message or the code window with the error highlighted.
Hi we have a SSIS package that calls an execute process task.
The task accesses a saved sql file in the directory, the agent that runs our task does have permission to access all these files. Yet when the package is executed it hangs at the execute process task, no processes are running but the package still is, all the previous tasks complete successfully until it reaches the execute process task
Hi if anyone is looking for the same problem we came across the answer, the cmd window required user input and therefore could not continue with the process until the cmd process task has finished and it never does.
So in short make sure your cmd process doesnt require user input if you are deploying to SSISDB or it will hang and you cant do anything about it
Error :
Argument "ETL" for option "connection" is not valid.
The command line parameters are invalid. The step failed.
While executing the Job in SQL Server Agent.
This is often a problem with parameter configuration, see e.g. here.
When you run from inside BIDS, you are in an environment where your parameters are available. When you schedule an SSIS package as a SQL Server job, those parameters have to come from somewhere. You can reference them in a configuration file, and you can override them in the configuration tab for the job.
Today I faced exactly same issue and I fixed it. What I did is, renamed connection name (without space, dots,hyphen) in my SSIS package. Previously I had default connection name so it showed error as
Argument "****" for option "connection" is not valid. The command line
parameters are invalid. The step failed.
later I changed both source and destination connection names(without space) and used those packages while scheduling Job in SQL Server Agent and tried Start Jot at Step and succeeded.
I had a similar issue where the paramater value ended in a backslash. I just removed it and appended it back in an expression within the SSIS package.
I also had a similar problem, I made a change deployed and it stop working, I tried to remove spaces and hyphens as suggested above (I have 2 connections at fault) and still nothing, well it did make an effect as in the error message switched from one connection to the other - arrrgh, after pulling all my hair out all day. I just had a thought to delete the job and recreate and it worked! Also BIDs I definitely think there is some kind of configuration bug in that after you deploy and try to manually change the connection manager it fails, so my workaround is to configure first, then deploy, (delete existing job if present) then create the job, so repeat for each environment u need to deploy to.
We are using swi-prolog to run our testcases. Whenever the test starts, I am opening the connection to MYSQL database and storing the Name of the Test hat is being done and then closing the DB. These tests run for about 2 days continuously. After the tests are done, the results basically gets stored in folder in the server. There is a predicate in another prolog file that is called to update the results to the MYSQL database. The code is simple, I use odbc library and just call odbc_* predicates to connect and update the mysql by issuing direct queries.
The actual problem is :
If I try to call the Predicate from the same Prolog window, where the test just got completed, I get an error as updating to the DB server. Although I do not get any error in the connection. If I close the session of that prolog with halt and closing all the open prolog windows , then open an other complete new instance of Prolog and run the predicate the update goes well.
I have a feeling that there is some connection reference to the MySQL DB in Prolog database. Is there any way to clear the database in prolog so that I can run the same predicate without closing any existing prolog windows?
Any ideas appreciated.
Thanks.
If you open the connection, than do a long processing, MySQL can drop the connection in between after a certain timeout (that I believe can do configured in my.cnf).
EDIT: swi-prolog has an odbc_disconnect that can be used to explicitly close the connection after using it and an "aliasing" mode that can be used to obtain a previously opened connection when using odbc_open. In you case you can try either closing the connection after using it. You should also avoid using an alias when opening.