I have a stored procedure created some time ago, actually in 2016 and it is set to run every year in the first day. The procedure automatically ran in 2017.01.01 but now in 2018 this did not happened automatically and i had to trigger it manually. Do you have any hints of what can i check to see what went wrong?
Below you can find the requested details:
DB2 server operating system: Linux ;
DB2 version: 10.1.3.0 ;
Scheduler: I am using cron.
I have checked the ADMIN_TASK_LIST and the END_TIME column is NULL, so from my point of view this should never stop running;
2.On first of January there is no entry for this in 2018, only in 2017;
I will check the files and let you know ;
I don't find any ATS_TASK_LIST, do you mean ADMIN_TASK_LIST?
I have checked db2diag and there was a space error identified but as per my colleagues feedback should have nothing to do with this. Also, i want to mention that yesterday we have created a test task which was set to be executed today at a certain hour and was not triggered. I have attached an image with the TEST task details in order for you to see if there is anything set wrong. Also, here is the error that i was talking about:"The Event Monitor "DB2DETAILDEADLOCK" has reached its file capacity"
TEST TASK IMAGE
It appears you don't know what schedules your job.
If cron is the scheduler (as you originally wrote), then most likely your question has nothing to do with Db2, see checks at the end of this answer. If you lack the skills with cron, ask your linux admin or study the docs and there's plenty of online info.
If the Db2 Administrative Task Scheduler (ATS)is the scheduler (as you subsequently imply from your comments), then the problem can be with Db2. Cron has nothing to do with the ATS, they are unrelated. So then your question is "why did ATS not run my job". This is also often asked.
Suggested checks for ATS jobs.
Check if the job is still present in ADMIN_TASK_LIST with correct definition , especially the END_TIME column.
Check if there is an entry in ADMIN_TASK_STATUS for this job on 01-January and study the entry for details of why the job failed
If the job is present in ADMIN_TASK_LIST with correct definition, and if there is no entry for the job in ADMIN_TASK_STATUS then check if the db2acd is still running, and check if db2acd has run out of memory (evidence in db2diag). I have seen that stopping db2acd cures this problem (Db2 watchdog will immediately restart db2acd).
If you are still stuck then edit your question to show the ATS_TASK_LIST entry and the ADMIN_TASK_STATUS entry for the failed run. Take care to give accurate responses to requests for clarification.
============================================
If cron is the scheduler, the advice below applies:
It is likely that your question is "why did cron not run my job".
That is a frequently asked question, so you can research that (there are many pages giving advice on that topic).
See https://unix.stackexchange.com/questions/207/where-are-cron-errors-logged
Check the crontab entry to ensure it is still valid.
Check the cron entry command (usually a script) still exists, and has
the correct permissions and that it can run with the
account specified .
Investigate the cron log file (if that is still available) and study that file
for clues . This will show if cron attempted to start the job, and what the exit code was.
When cron fails to run a job and that job had some output, cron emails the crontab owner with the output of the failed job.
But this can depend on the exact command that is in the cron entry
(in case it redirects stdout and stderr to some file instead, in
which case you should consult that file).
If the cron entry does not redirect stdout/stderr, and the script/command gives output when run then refer to the mailbox of the cron owner to see what emails arrived on first of january.
Related
I need to get the exact time when the build has triggered(build periodically option currently using). Because of the configuration only 3 tasks can run in parallel. Consider 3 tasks are running in parallel now. So the executor will be putting the next task in Waiting for the next available Executor state. So I need to access this waiting time or exactly when it is started as date means when its triggered.
I have used Build Timestamp Plugin also. But no use. It is giving the time when the build steps has started. So can anybody help me do this? Thanks.
I have found one solution which I'm going to share now. If anybody is in the same situation, this might help them.
build_details = get('http://localhost:8080/jenkins/job/<jobName>/api/xml?tree=builds[id,queueId]&xpath=//build[id=<buildId>]')
queueId = build_details['build']['queueId']
queue_details = get('http://localhost:8080/jenkins/queue/item/<queueId>/api/json')
job_queued_time = Time.at(queue_details['inQueueSince'] / 1000.0).to_time.utc
Note: I've posted pseudo code, not a full solution. You have to port it to your language. <jobName>, <buildId>, <queueId> are variables, please replace them.
Here, localhost:8080 is same for everyone because, that is going to run in Jenkins machine itself. Mostly my solution works for single node Jenkins(i.e. No master-slave architecture). I haven't tested it in master-slave though.
Recently, in our enterprise production setup, it seems someone has tried to setup a new job / test definition by using another (copying) from identical job. However, (s)he seems to have NOT saved (and probably, am guessing here, closed the browser with the session being lost).
But the new job got saved though it was not set to stable or active; we knew about this because changes uploaded to gerrit, started failing in this newly setup partial job (because, these changes were in certain repos that met certain TDD settings).
Question: Jenkins system does not have trace of who setup the system in 'configure versions' option. Is there anyway to know the details of who setup the job / when was that done ?
No, Jenkins does not store that information by default.
If your Jenkins instance happen to be running behind an Apache or Nginx web server, there might be access logs that can help you. To find out when the job was created you could look at when its config.xml file was created/modified.
However, there are a few plugins that can add this functionality so that you won't have this problem again:
JobConfigHistory Plugin – Tracks changes in your job configurations and gives the ability to restore old versions.
Audit Trail Plugin – Keeps a log of who performed particular Jenkins operations, such as configuring jobs.
I am using Jenkins to deploy changes to a system which manages and runs lots of different jobs which are scheduled daily. We have a staging setup which does not write to the real database, and a production setup which does.
The Jenkins flow I would like to have a happen when a change is pushed is this
Run checks.
Deploy to the staging system.
Wait 24 hours.
Check logs to make sure that the staging system has not had any errors in the last 24 hours.
Deploy to the production system.
There could be more than one of these builds running concurrently at any time - eg. I push changes at 11 am, they are deployed to staging. At 5 pm I push more changes and they are also deployed to staging. The next day at 11 am the first set of changes only are deployed to prod. At 5pm that day the second set of changes are deployed.
Now, I have managed to build a system which does this, by using the Build Flow Plugin, and creating a job called wait_one_day which runs sleep $((24 * 60 * 60)) in a bash shell.
This doesn't seem like the most elegant solution, and has the disadvantage that I am tying up two Build Executors for 24 hours (one for the build flow job, and one for wait_one_day), each time we make a change.
Is there any better way of doing this, or any plugin which is designed to help with this process? Can a Jenkins job schedule another Jenkins job to run as a one-off?
I would equally be happy to hear about an alternative approach to solve the same problem if anyone has any suggestions or constructive criticism of my design.
There was similar SO question recently that I answered, although I'm not sure that my answer there exactly fits your scenario.
You could potentially dynamically create a job that does steps 4 & 5 which would run periodically every 24 hours. The catch here is that you would actually only run this job once, and have a build step in that job that deletes itself (groovy code or shell script). It would be easy enough to create a deactivated template job that you could just clone and then modify for the particular task. An intermediary job would be necessary which would trigger upon completion of any job that runs steps 1 and 2. The intermediary job would then create the temporary job from the template.
Alternatively, you could create some sort of handler, either within jenkins or external that would run off of some properties file or database containing the scheduling for when jobs need to be fired off. Granted, if you are going to go the route of writing a handler, you might consider putting in a little extra effort and writing a jenkins plugin...
i know there are several issues with a topic close to this one. But as fas as I searched i did not found a thread/question with the same topic.
So here is the situation:
On our Jenkins Server we a many build jobs (maybe a few hundred). Some of them running on Slaves, some on the master. Now i was asked to change settings of some of them (lets say 50), so the have project based security and I had to change the slave server they are running on. Before they ran already on a Slave, but a different one.
The Problem:
In the beginning everything went fine. I changed the settings ob several jobs quick and startet to change the settings of the next job. But after some time the configuration settings began to load slower and slower. First it were a few secounds(after 10 Job), then a few more secounds (after 20 jobs), then like one minute (after 30 jobs) and now several minutes (after 40 jobs). I open every settings page in a new tap and close the tab once I finished my configurations.
My Question:
Why does it take Jenkins so long to open up the configuration page? Especially because in the beginning there was nearly no loading tim and now after I changed a few jobs i have to wait minutes for it. What could be the reason?
You need to see in the first step what is configuration of this new slave,
Issue can be memory based, so on master instance check the memory usage and check the java process, can be done with strace -p <PID> depends on your environment.
Instance can be slower due to memmory usage which is in the most cases.
We've inherited a set of Jenkins builds. They all seem to start 90-100 seconds after the desired time. For example, a build with a schedule of */5 * * * * starts at :01:37, :06.29, :11:43, etc., instead of :00, :05, :10, etc. that I would expect.
There are a few builds set to run at /5, but they are all delayed and anyway only last a few seconds each.
I see a global 'quiet period' setting of 5.
The system as a whole does not seem busy. There are usually idle executors, and often nothing at all is building.
For most of the builds this isn't a concern, but there are a couple that we would like to make as precise as possible.
Is my expectation wrong? Is there a config option I'm missing? I should add that I am new to Jenkins and may be missing something obvious.
Thanks
We did not find the cause of Jenkins jobs starting late. We hacked up a workaround by having Jenkins start a script on the remote server that sleeps until the desired time. This creates a new problem by tying up a Jenkins executor for several minutes, so we have the remote script spawn a wait task and then return to Jenkins immediately. This creates another problem in that the output of the remote script is lost because when it completes it has no connection to Jenkins anymore. We get around that by having the remote script write its results into a tmp file, and returning the results of the previous run.
So we have a seriously hacked-up solution that actually works fine for our purposes.
We updated Jenkins from 1.492 to 1.565 and the problem went away. Jobs now start within a few seconds of the expected time.