Re: pgAgent STDERR and Time Zone Questions

2012/1/10 David E. Wheeler <david(at)justatheory(dot)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(at)pgadmin(dot)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 exactly the 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 version of 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