Running batch&job can't show start-end time and can't show the detail of batch&job runnning

55 views
Skip to first unread message

Jo Sirisak

unread,
Sep 4, 2024, 10:46:14 PM9/4/24
to schedulix

Hi Schedulix support,

I appreciate your supporting my problem, I have problems with

  • Running master jobs can not show Start-End time for all of batch&job after 2024/09/01 (past 11 months are working normally)
    • All plans since created on 2024/08/31 are fine for normal usage (All jobs running 2024/09/01 are show start-end time and detail on click normally)
  • I can't see the detail all of batch&job after 2024/09/01 when I clicked seeing the detail of batch/job, I saw the error log in /zope5/var/log/event.log from below that


2024-09-01 15:13:46 ERROR [Zope.SiteErrorLog:252][waitress-1] 1725178426.91087220.9744011758755813 http://192.168.115.98:8080/SDMS/SDMSDesigner/Jobs/EditorDisplayPage Traceback (innermost last): Module ZPublisher.WSGIPublisher, line 167, in transaction_pubevents Module ZPublisher.WSGIPublisher, line 376, in publish_module Module ZPublisher.WSGIPublisher, line 279, in publish Module ZPublisher.mapply, line 85, in mapply Module ZPublisher.WSGIPublisher, line 68, in call_object Module Shared.DC.Scripts.Bindings, line 333, in __call__ Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec Module Products.PythonScripts.PythonScript, line 349, in _exec Module script, line 1, in EditorDisplayPage - <PythonScript at /SDMS/EditorDisplayPage used for /SDMS/SDMSDesigner/Jobs> - Line 1 Module Shared.DC.Scripts.Bindings, line 333, in __call__ Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec Module Products.PythonScripts.PythonScript, line 349, in _exec Module script, line 410, in DefaultEditorDisplay - <PythonScript at /SDMS/Common/Pages/DefaultEditorDisplay> - Line 410 Module Shared.DC.Scripts.Bindings, line 333, in __call__ Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec Module Products.PythonScripts.PythonScript, line 349, in _exec Module script, line 79, in DefaultEditorData2REQUEST - <PythonScript at /SDMS/Common/Util/DefaultEditorData2REQUEST> - Line 79 Module Shared.DC.Scripts.Bindings, line 333, in __call__ Module Shared.DC.Scripts.Bindings, line 370, in _bindAndExec Module Products.PythonScripts.PythonScript, line 349, in _exec Module script, line 133, in EditorData2REQUEST - <PythonScript at /SDMS/SDMSDesigner/Jobs/EditorData2REQUEST used for /SDMS/Common/Util> - Line 133 Module Products.ExternalMethod.ExternalMethod, line 240, in __call__ - __traceback_info__: (('01 Sept 2024 01:00:11 GMT', '%d.%m.%Y %H:%M:%S', 'Asia/Bangkok'), {}, ('%d.%m.%Y %H:%M:%S', None)) TypeError: 'NoneType' object is not subscriptable


Please help me to solve it, thank you so much


Our Schedulix server details

Schedulix 2.10 Zope 5.1.2 Python 3.6.15 Java java-17-openjdk-17 Java PostgreSQL Driver postgresql-42.6.0.jar OS SUSE Linux Enterprise Server 15 SP5 PostgreSQL 15.4 on x86_64-pc-linux-gnu, compiled by gcc (SUSE Linux) 7.5.0, 64-bit


(I hide the job name)

capture_schedulix_detail-of-batch-and-job.pngcapture_schedulix_master-running-jobs.png

Ronald Jeninga

unread,
Sep 5, 2024, 4:34:13 AM9/5/24
to schedulix
Hi Jo,

well, this is weird, to put it mildly.
My first thought was: did something change since September 1st (or August 31st)?
Did you install a newer 2.10 server or SDMS.zexp? Or any other software on your system?
On the other hand, that wouldn't explain why all datetimes before September 1st are rendered correctly and only those after August 31st are not.

BUT! Looking at git log output (in BICsuite, not schedulix), I've noticed the following:

ronald@oncilla:~/SDMS-2.10/SDMS/src/zope4/Extensions$ git log sdms.py
commit ff56b54df77fd59528a785e4aa62a0ee955d7231
Author: Ronald Jeninga <ronald....@independit.de>
Date:   Fri Sep 1 12:05:27 2023 +0200

    In some situations September is abbreviated with Sept instead of Sep, which broke our date formatting functions


The corresponding change modified the next function into:

def numericTime(s):
        # local not supported under windows
        # since we are using english anyway we skip that
        # locale.setlocale(locale.LC_ALL, 'en_GB')
        # we cut off the first 21 characters, even if that's too much in most cases
        # But in some environments "Sep" is rendered as "Sept" instead, which makes the date string one character longer
        # The whole idea of using the first 20 or 21 characters is to chop off the time zone.
        # And if we use 21 characters, we'll get a blank at the end of the date string but don't lose a digit of the seconds
        # in case of "Sept". The parsedate_tz() function doesn't mind the trailing blank
        pt = parsedate_tz(s[:21])
        # ts = time.mktime(time.strptime(s[:20], '%d %b %Y %H:%M:%S'))
        ts = time.mktime(pt[:9])
        return ts

Now if you happen to use an elder release of sdms.py, you'll find it does something like

                 pt = parsedate_tz(s[:20])

instead and the additional "t" after Sep will then cause a digit of the seconds to miss, which will confuse parsedate() and have it return a None instead of some value.

The sdms.py script should be in $BICSUITEHOME/zope4/Extensions.
And in the Exiensions directory of your Zope instance there should be a symbolic link pointing to the sdms.py mentioned.
If you modify the sdms.py script (if my hypothesis turns out correct) and restart your Zope server, things should work again.

Updating your system to the latest 2.10 (or even upgrading to 2.11) should work as well.

If I'm wrong, please advise.

Best regards,

Ronald

fab...@gmail.com

unread,
Sep 5, 2024, 6:01:35 PM9/5/24
to schedulix
Hi Ronald,
i ran in the same error.  change de sdms.py and doesn't work.
Regards
Fabio
schedulix.png

fab...@gmail.com

unread,
Sep 5, 2024, 6:07:29 PM9/5/24
to schedulix
additional info: schedulix 2.11 works fine, no problem at all.

fab...@gmail.com

unread,
Sep 5, 2024, 6:09:04 PM9/5/24
to schedulix
updating to latest 2.10 solved the problem! thanks again ronald!

Ronald Jeninga

unread,
Sep 6, 2024, 2:18:35 AM9/6/24
to schedulix
Hi Fabio,

thank you for reporting this!
I've investigated the change a little further and at least if you use Java 17 a change in the server's source code is required too.
That might be true as well when using other Java releases.

Thanks again,

Ronald

Jo Sirisak

unread,
Sep 6, 2024, 2:39:46 AM9/6/24
to schedulix
Hi Ronald and Fabio,

Thanks for your suggestion, I tried to use Ronald workaround and couldn't solve the problem and then I got the same error from Fabio. 

I found the root cause I use java jdk17 (I installed Jenkins Agent latest version in the same Schedulix server) following from https://stackoverflow.com/questions/67089932/simpledateformat-format-month-september-jdk16

Ref Java document

So this problem I can fix this with
- Upgrade Schedulix server from 2.10 to 2.11
- Change alternative java or change parameter java home to pointer to java jdk8
 
Thank you for everyone to help me ;) 

Have a good day. <3

ในวันที่ วันศุกร์ที่ 6 กันยายน ค.ศ. 2024 เวลา 13 นาฬิกา 18 นาที 35 วินาที UTC+7 Ronald Jeninga เขียนว่า:

Ronald Jeninga

unread,
Sep 7, 2024, 1:00:39 AM9/7/24
to schedulix
Hi Jo,

thank you for your background research!
Basically it is related to the locale settings. Previously we used en_GB internally, not because it is better, but because we're from Europe.
But all of a sudden the Brits decided that Sept is the better 3 letter abbreviation for September, which was, as your research shows, implemented in Java 16.

The main fix within the scheduling server was to set the locale to en_US.
But the fix in sdms.py is required as well, else the last digit of the seconds is cut off in case a "Sept" slips through.
This might happen easily if your system locale is set to en_GB.

Anyway, I'm happy your installations are back to work now.

Enjoy the rest of your weekend!

Best regards,

Ronald

Reply all
Reply to author
Forward
0 new messages