I have scheduled windows task scheduler to upload different text files to oracle database. Till date its working fine. But i have an issue that if any uploading was disrupted because of following reasons.
1) Database Machine Shutdown
2) Internet Connectivity Issues
3) Miscellaneous
How i will get this information about failure of task scheduled?
Windows itself (in the event log; a filtered view for each scheduled task is available in the Task Scheduler application) will record if the task failed.
For anything more you'll need to add diagnostic logging to your task's implementation.
Related
I want to know if it is possible to configure a service to call a batch/powershell script when I stop it from services.msc.
While in Linux init.d services are fully programmable and even systemd services can have additional procedures I've yet to find a way to accomplish this on Windows.
Thanks in advance
You can configure services to run a program on failure, but if you are stopping the service via services.msc then that likely wouldn't count as a failure.
The only other option I can think of would be to set up a PowerShell script running as a scheduled task that either periodically checks the services running status, or (for a more foolproof option) looks at the event log for events indicating that the service has been stopped (since the last time the script checked) and then performs whatever actions you require.
Per the comment from montonero, you wouldn't need to run the scheduled task periodically as it could be configured to run when the event itself occurs. This is described here: https://blogs.technet.microsoft.com/wincat/2011/08/25/trigger-a-powershell-script-from-a-windows-event/
Use the Event Viewer “Attach Task to This Event…” feature to
create the task.
Launch "Event Viewer" and find the event. Once found, right-click on the event and select "Attach Task to
This Event...".
I have a windows task running on windows server via Task scheduler. It is scheduled to run indefinitely. When the server password is expired after set period or is changed, the task stops running and then we have to change the password in task scheduler for keeping it running. Is there any way we can remove this dependency of password in task scheduler.
the only thing I think would work is to connect it to some password manager, and read from there (I know we did something like this with https://www.passwordstore.org/)
then you only need to have your own accepted gpg keys to read from there
I am trying to kill a background task that is in progress in m sonarqube.
This task is doing a scan on a project.
I connected to sonarqube DB and I executed this query to retrieve the "in progress" job
select * from ce_queue where status<>'PENDING';
Then I deleted the record delete from ce_queue where id=2325;
In-progress tasks cannot be canceled for the moment
I also continue to have this problem with Enterprise EditionVersion 7.2.1 (build 14109). It's ridiculous that this problem has persisted for years and it's a big deal because it takes one of your workers out of the pool.
The only way I have found to kill the task is to delete the entire project that is associated with the task. Restarting the service / rebooting (to catch other processes, etc) / none of this helped.
Deleting the project kills the task
you're welcome
In my windows task scheduler, I have scheduled a task to run a c# console application executable on a daily basis. This application sends some data to the database and then sends an email.
When I run it normally it works but however when it is run through task scheduler, it sends data to the database but is unable to send the email.
Any ideas on how to fix this?
EDIT:
Yes I can send correctly through console application. It uses default network credentials..However when I look at the event logs I have the following .NET Runtime exception logged:
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.IOException
Stack:
at iTextSharp.text.pdf.PdfPages.WritePageTree()
at iTextSharp.text.pdf.PdfWriter.Close()
at iTextSharp.text.pdf.PdfDocument.Close()
at iTextSharp.text.Document.Close()
at ReadReutersRates.Program.SavePDF(System.DateTime)
at ReadReutersRates.Program.Main(System.String[])
I think it has something to do with pdf file which I am attaching to the email. But it's quite strange that this works when I manually run it.
This is a permissions error, the user you're running the task as when running through the console will have more permissions than the user running the task.
It appears the PDF app you are using is trying to write to a temp file or similar and it doesn't have permissions. (I'm assuming the email has a PDF attachment or similar that is being generated on the fly)
If you made your task run as an administrator that should work, you could then run it as a more restricted user and work out which permissions to apply to where to lock it down.
on each of our remote servers a scheduler task is created that calls an .exe program that shuts down the databases at 10:00:00 everyday (it create database backups)and start it up again at a specific time.now using the delphi application i need to now how can i check if the scheduler task backups were ran successfully(database shutdown and startup)...the ideas was to try and connect to the scheduler Task using delphi application and check the last run time(when didi it last execute or run the .exe using the DATETIME variable),status(is it running)..please assist i can connect to the server in delphi but i cant connect to the scheduler task in the server.
This is what I'm doing for my own automated backups: The application that does the actual backup updates a DATETIME column in the database with the last successful backup date and time. From the usual client application I can read the given DATETIME column and issue warnings if backups are getting old.
Advantages: Nothing complicated about it (KISS!), no need to figure out API's to read the scheduler, no need to figure out "exit codes" for when the backup started but wasn't successful, works even if backups are being made from multiple locations.