PSA: 12.1 with Oracle seemingly not deactivating JOBP

[Carsten Schmitz]

Aloha.

Anyone on Oracle with 12.1? Remember the funky error message from my V12.1 findings?

It appears it's not just when you manually want to deactivate a job plan. It appears the system can not deactivate JOBP either, I suspect this has to do with Oracle. Would appreciate a shout if someone else is on Oracle with 12.1 (or 12.0 maybe) about your mileage.

Currently our 12.1 system has 16000 active JOBP and overall 50000 objects in a non-deactivated state after about three weeks, because seemingly no job plans are ever deactivated:

https://us.v-cdn.net/5019921/uploads/editor/tm/mr104u2gt3bs.png" width="583">

Of course, nobody will readily see this, because the counters in the activity window (not just the list, but the overall counters also) only count to 500. If you add all the categories of the counters, it's always 500:



Uhm, well.

In any case, I bumped the severity of the open incident.

Best regards,
Carsten

edit, p.s.: just to be sure I'm not barking up the wrong tree, I made a totally empty JOBP and set it to "always deactivate". I ran it. It triggers the log message, and does not deactivate.

[Karin_Wasinger_8156]

Hi Carsten_Schmitz_7883 ,

we need to ask internally how the calculation is done and we will get back to you via the ticket as soon as we have more information.

 

In the meantime you could set in the UC_SYSTEM_SETTINGS the parameter COMBINED_ACTIVITIES_LIMIT to a higher value as the default (=500). With this setting more activities can be displayed in the Process Monitoring and the calculation will be also raised to the new limit you've set in the UC_SYSTEM_SETTINGS Variable.

 

See also our Documentation:

https://docs.automic.com/documentation/webhelp/english/AWA/12.1/DOCU/12.1/AWA%20Guides/help.htm#AWA/Admin/admin_UC_SYSTEM_SETTINGS.htm?Highlight=COMBINED_ACTIVIES_LIMIT

Best regards,
Karin Wasinger

[Carsten Schmitz]

Hi Karin_Wasinger_8156

Thanks for the tip. I upped it to 10000 entries.

The good: the system, and AWI survive unscathed
The bad: there is a hard limit at 5K

https://us.v-cdn.net/5019921/uploads/editor/ys/dz784e021yv2.png" width="325">
                Pictured: five kilos of activities

The statement I expressed in my ticket, about a requirement for an absolute counter for the admin that is not linked to the amount of entries displayed in the activities list, remains valid of course (as I believe you have already pointed out).

Best,
Carsten Schmitz

p.s. dear reader: if you believe that this thread was in a strange language from a far away land for a little time, I can assure you that is merely an illusion. It is, as you can see, now ... erm ... I mean it has always been English from the onset :p

[Carsten Schmitz]

Good news - we have found the problem. Automic support got us on the right track by suggesting to check into any possible differences of the Oracle "driver". It turned out it was not related to the Oracle driver as such, but this made us investigate the environment of the respective server processes.

The $LD_LIBRARY_PATH had a path like "/some/path/ae/12/utilities/bin", which contained the files for version 12.1. Among those some Automic shared objects.

When my colleague made the ZDU to 12.1.1, the $LD__LIBRARY_PATH remained as it were. Thus, the 12.1 shared objects were still being loaded.

This, in turn, led to those seemingly totally unrelated Oracle error messages and who-knows-what-other side effects starting with 12.1.1.

So ultimately, this problem was on our part.

However, I'll nevertheless say that this problem, eventhough rooted in a mistaken configuration on our part, should give Automic some pause. The obvious questions here are:

• if such relatively minor oversight can lead to seemingly totally unrelated major malfunctions that are so hard to pinpoint that (unfortunately) both the client and Automic spent a good number of hours looking into it - maybe that should simply been prevented? Maybe the shared objects should be versioned, and the AE just not start in this case, or print a proper error?
  
  Linux best practice is to "version" shared objects, e.g. libflamingo.so.5. Automic apparently chose to not do that. ZDU makes it much more likely to overlook this. Especially because:
  
  
• Maybe the ZDU should make it well clear that people need to check their $LD_LIBRARY_PATH. At present, to my knowledge there is no such mention or instructions to do so.

Best Regards,

Carsten

[Carsten Schmitz]

Idea: Versioning of the shared objects.

 

Not open for voting yet.

 

FOKUS: Versioning of the AE shared objects 

[Michael A. Lowry]

Carsten Schmitz said:

p.s. dear reader: if you believe that this thread was in a strange language from a far away land for a little time, I can assure you that is merely an illusion. It is, as you can see, now ... erm ... I mean it has always been English from the onset :p

If we shadows have offended, 
Think but this, and all is mended,
That you have but slumbered here
While these visions did appear.
And this weak and idle theme,
No more yielding but a dream,
Gentles, do not reprehend:
If you pardon, we will mend:
And, as I am an honest Puck,
If we have unearned luck
Now to 'scape the serpent's tongue,
We will make amends ere long;
Else the Puck a liar call;
So, good night unto you all.
Give me your hands, if we be friends,
And Robin shall restore amends.

[Carsten Schmitz]

Who would have thought this little piece,
now off-topic, so the banhammer I fear,
on Automation Engine's shared libraries,
leads us to him: Sir William Shakespeare.

For versioning of libraries we need,
even Shakespeare must have heard!
So his eternal words y'all shall heed,
for ol' Will Shakespeare says: Word!

(Thank you, good night and drive carefully).