Re: pgAgent STDERR and Time Zone Questions - Mailing list pgadmin-support
From | Dave Page |
---|---|
Subject | Re: pgAgent STDERR and Time Zone Questions |
Date | |
Msg-id | CA+OCxozraMwSTB+PoAeTXR5JamSzGiBW6Sr+Ovp3xBKr8hiosA@mail.gmail.com Whole thread Raw |
In response to | Re: pgAgent STDERR and Time Zone Questions ("David E. Wheeler" <david@justatheory.com>) |
Responses |
Re: pgAgent STDERR and Time Zone Questions
|
List | pgadmin-support |
2012/1/10 David E. Wheeler <david@justatheory.com>: > > Finally got back to this. Naturally, the car works perfectly when it’s in the shop. Of course - that's all part of the game :-) > I installed the pgrpms version of pgAgent, which Devrim uploaded a few weeks ago. > > http://yum.pgrpms.org/9.1/redhat/rhel-5-i386/pgagent_91-3.0.1-1.rhel5.i386.rpm > > With that, I can create a job with a single batch step. All it does is this: > > perl -e 'die "WTF"' > > That results in: > > postgres=# select * from pgagent.pga_jobsteplog where jslid = 8; > -[ RECORD 1 ]----------------------------- > jslid | 8 > jsljlgid | 8 > jsljstid | 1 > jslstatus | f > jslresult | -1 > jslstart | 2012-01-10 14:28:26.95867-08 > jslduration | 00:00:00.011809 > jsloutput | > > Which seems fine. Then, with the patched version from SVN, I fire it up and run the same job and get: Yup. > postgres=# select * from pgagent.pga_jobsteplog where jslid = 9; > -[ RECORD 1 ]------------------------------ > jslid | 9 > jsljlgid | 9 > jsljstid | 1 > jslstatus | f > jslresult | 255 > jslstart | 2012-01-10 14:34:05.243314-08 > jslduration | 00:00:00.008179 > jsloutput | > > Which is different, but at least still a failure. (Nothing was logged; I ran it with `/usr/bin/pgagent -s /home/dwheeler/pgagent.log-l DEBUG hostaddr=127.0.0.1 dbname=postgres user=postgres`.) Hmm, I suspect the difference in return values is as a result of this: raptor:pgagent dpage$ git show 2aec3bc473e583f8fa07e133bc8def60ff1c09fe commit 2aec3bc473e583f8fa07e133bc8def60ff1c09fe Author: Dave Page <dpage@pgadmin.org> Date: Mon Mar 14 08:58:43 2011 +0000 USe exit status macros to get the Unix exit code, and recognise all non-zero return values as failure codes. Per discussion with Korry Douglas and Robert Haas. diff --git a/job.cpp b/job.cpp index 0611c93..4cb3b8c 100644 --- a/job.cpp +++ b/job.cpp @@ -284,8 +284,11 @@ int Job::Execute() } rc=pclose(fp_script); - rc = (unsigned char)(rc >> 8); // The exit code is in the top 8 bits - rc = (signed char)rc; + + if (WIFEXITED(rc)) + rc = WEXITSTATUS(rc); + else + rc = -1;#endif // Delete the file/directory. If we fail, don't overwrite the script output in the log, just throw warnings. @@ -313,7 +316,7 @@ int Job::Execute() } wxString stepstatus; - if (rc >= 0) + if (rc == 0) stepstatus = wxT("s"); else stepstatus = steps->GetString(wxT("jstonerror")); We haven't released a new version since then. I'm somewhat mystified about the lack of log data though - that's just plain odd. I assume it's not dumping it to stdout (which should only happen if a logfile isn't specified - which you seem to have done)? > Going back to the box that originally had this problem, which also uses Devrim’s RPM, I created a new test job with exactlythe same step as above. There I get: > > postgres=# select * from pgagent.pga_jobsteplog where jsljlgid = 155; > -[ RECORD 1 ]------------------------------ > jslid | 177 > jsljlgid | 155 > jsljstid | 21 > jslstatus | s > jslresult | 5 > jslstart | 2012-01-10 22:18:42.995252+00 > jslduration | 00:00:00.013335 > > Which just seems wrong. Both boxes are running CentOS 5.5 (Linux 2.6.18-194.el5). Might there be a difference in the versionof Wx installed or something to account for this? Are both systems 32bit? I can't imagine a wxWidgets version would cause such a difference - the code that handles the return values is mostly pure C++, and the wxWidgets code that is there is so common (things like wxT, wxString) that we'd see weirdness all over the place in a bunch of apps if that was broken. Devrim; any chance you could whip up a test RPM from GIT master for us please? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgadmin-support by date: