Time |
Nick |
Message |
04:50 |
|
JBoyer joined #evergreen |
06:59 |
JBoyer |
uggghh... jeff's right, mod_idlchunk does indeed have a buffer_free call that will need to be changed to osrf_buffer_free. So the 503 is coming from nginx as the apache process just evaporates just like it was in lp 1999823. |
06:59 |
pinesol |
Launchpad bug 1999823 in OpenSRF "Name collision causes apache gateway modules to fail when mod_shib is installed" [Medium,Confirmed] https://launchpad.net/bugs/1999823 |
07:55 |
|
kmlussier joined #evergreen |
08:06 |
|
BDorsey joined #evergreen |
08:10 |
|
kmlussier joined #evergreen |
08:32 |
|
kworstell-isl joined #evergreen |
08:33 |
|
Stompro joined #evergreen |
08:34 |
|
collum joined #evergreen |
08:40 |
|
mmorgan joined #evergreen |
08:42 |
|
dguarrac joined #evergreen |
08:46 |
|
Dyrcona joined #evergreen |
08:48 |
JBoyer |
So I posted a branch to that bug for Evergreen, but if we have to make changes to Eg we should just move all buffer_* calls to osrf_buffer_* and just be done with it. :-/ I can try to do that sometime soon if no one else wants to grab it. (It's basically a simple mechanical change across 15 files) |
08:48 |
Dyrcona |
I say, "Go for it!" |
09:04 |
|
rfrasur joined #evergreen |
09:20 |
Dyrcona |
Circular error reference is circular: Event reacting failed with Exception: OpenSRF::EX::ERROR 2023-08-17T04:23:45 OpenILS::Application::Trigger::EventGroup /usr/local/share/perl/5.30.0/OpenILS/Application/Trigger/EventGroup.pm:98 System ERROR: Call to open-ils.trigger for method open-ils.trigger.event.autocreate |
09:22 |
Dyrcona |
The error message point back to the line where the exception is raised, and the final method in the list is the one that called event group fire.... |
09:24 |
Dyrcona |
"Inconceivable!" In this case the stderr log may actually be useful since it contains exactly 1 line and was updated at the time of the above error. |
09:30 |
Dyrcona |
It failed searching for the hooks, which suggests something happened with cstore. |
09:36 |
Dyrcona |
At that point it gets murky because I can't guarantee that the cstore searches I see are for this particular event, but there is one that returns 0 results about that time. |
09:38 |
Dyrcona |
Well, it's a search for an event definition with the hook "renewal" that fails. The search for the hook returned 1 row, and that might not be this event being processed. |
09:41 |
Dyrcona |
OK! There's one open-ils.cstore.direct.action_trigger.hook.search.atomic with request returned no data. |
09:43 |
Dyrcona |
A circ drone(?) is not connected to the network.... |
09:44 |
Dyrcona |
No weird messages from the drone in osrfsys.log. |
09:45 |
Dyrcona |
open-ils.cic._stderr.log hasn't been touched since July 5. |
09:45 |
Dyrcona |
That's where the story ends. |
09:47 |
Dyrcona |
So...Why would a circ drone being disconnected cause $editor->search_action_trigger_hook() to return no results? |
09:47 |
Dyrcona |
I guess there was an epilogue... |
09:51 |
Dyrcona |
Only that circ drone is "NOT CONNECTED." No such messages related to cstore. |
10:00 |
Dyrcona |
No PostgreSQL errors at the time. |
10:05 |
Dyrcona |
No cstore errors, either.... |
10:06 |
Dyrcona |
Ah. Wait a minute... cstore logs the timestamp and service backwards. Has anyone mentioned that on LP? |
10:07 |
Dyrcona |
Still no warnings or errors from cstore. |
10:08 |
Dyrcona |
I guess the trail ends at a cliff. |
10:32 |
|
StomproJ joined #evergreen |
10:41 |
|
sandbergja joined #evergreen |
11:08 |
|
BrianK joined #evergreen |
11:09 |
|
kmlussier joined #evergreen |
11:36 |
|
collum joined #evergreen |
11:52 |
|
Dyrcona joined #evergreen |
12:26 |
jeffdavis |
I'll test that EG branch for 1999823 today |
12:28 |
Dyrcona |
Lp 1999823 |
12:28 |
pinesol |
Launchpad bug 1999823 in OpenSRF "Name collision causes apache gateway modules to fail when mod_shib is installed" [Medium,Confirmed] https://launchpad.net/bugs/1999823 |
12:38 |
|
kworstell-isl joined #evergreen |
12:46 |
|
kworstell_isl joined #evergreen |
13:18 |
|
kworstell_isl_ joined #evergreen |
13:19 |
|
kworstell-isl joined #evergreen |
13:52 |
jeffdavis |
JBoyer++ # initial testing suggests that mod_idlchunk branch resolves the issue - need to test further before signoff but feeling pretty optimistic. Thanks! |
13:54 |
JBoyer |
jeffdavis++ glad to hear it. I'd like to see the rest of the files in both OpenSRF and Evergreen switch to those funcs since neither fix is committed, but at least you should have everything you need to get things going locally. |
13:55 |
jeffdavis |
Should I open a new bug about changing the function names everywhere, or do we want to do it as part of this bug? |
13:56 |
|
kworstell-isl joined #evergreen |
14:04 |
JBoyer |
I think it should be a one-shot thing since it'll require syncing Eg and OpenSRF releases since you won't be able to mix and match old / new versions even on Debian / other systems. |
14:07 |
Dyrcona |
JBoyer: I don't think I understand that. Are you saying the function renaming should be a one shot thing or that fixing the Lp and the function renaming should be a one shot thing? |
14:07 |
|
kworstell-isl joined #evergreen |
14:08 |
JBoyer |
All existing uses of the buffer_* funcs should be moved to osrf_buffer_* in a single patch rather than just enough to get apache mods to work. The old names should be left in libopensrf because it should still be possible to install new OpenSRF and old Evergreen (so to speak) |
14:09 |
Dyrcona |
OK. Should that be included with this bug or a different bug? I am aware it requires a sync with OpenSRF. |
14:09 |
JBoyer |
But what I'd like to avoid is using osrf_buffer_* some places, buffer_* in others, while still saying that Eg X.Y can only be installed on OSRF Y.z |
14:10 |
Dyrcona |
We've limited certain Evergreen version to certain OpenSRF versions before, but usually just with major version updates: 3.0 for instance. |
14:10 |
JBoyer |
Doing everything in that 1 bug would be best. We know what's wong and how to fix it, we just have to fix it more than I did initially. |
14:11 |
Dyrcona |
I'm cool with that as long the release note indicates that OpenSRF and Evergreen have to be upgraded in tandem. (I'm cool with it being patch releases, too, though others might disagree.) :) |
14:19 |
|
collum joined #evergreen |
14:57 |
|
mmorgan1 joined #evergreen |
15:44 |
StomproJ |
oclc-- |
16:02 |
|
jvwoolf joined #evergreen |
17:09 |
|
mmorgan1 left #evergreen |
17:12 |
jeffdavis |
pushed a branch that does buffer_* -> osrf_buffer_* everywhere I could find, probably needs a look from someone more familiar with C |