| Time |
Nick |
Message |
| 00:14 |
|
sleary joined #evergreen |
| 00:18 |
|
collum joined #evergreen |
| 00:36 |
|
collum joined #evergreen |
| 01:52 |
|
collum joined #evergreen |
| 02:10 |
|
collum joined #evergreen |
| 03:28 |
|
collum joined #evergreen |
| 03:45 |
|
collum joined #evergreen |
| 05:03 |
|
collum joined #evergreen |
| 05:21 |
|
collum joined #evergreen |
| 05:38 |
|
collum joined #evergreen |
| 05:54 |
|
redavis joined #evergreen |
| 06:57 |
|
collum joined #evergreen |
| 06:59 |
|
redavis joined #evergreen |
| 07:07 |
|
sleary joined #evergreen |
| 07:55 |
|
BDorsey joined #evergreen |
| 08:13 |
|
collum joined #evergreen |
| 08:32 |
|
collum joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:54 |
|
dguarrac joined #evergreen |
| 09:09 |
|
mantis joined #evergreen |
| 09:14 |
|
Dyrcona joined #evergreen |
| 09:34 |
|
kmlussier joined #evergreen |
| 09:48 |
|
collum joined #evergreen |
| 10:02 |
|
sleary joined #evergreen |
| 10:06 |
kmlussier |
Good morning #evergreen! |
| 10:06 |
kmlussier |
@coffee [someone] |
| 10:06 |
* pinesol |
brews and pours a cup of Ethiopia Sidamo Guji, and sends it sliding down the bar to genpaku |
| 10:06 |
kmlussier |
@tea [someone] |
| 10:06 |
* pinesol |
brews and pours a pot of Earl Grey Decaffeinated Black Tea, and sends it sliding down the bar to gmcharlt_ (http://ratetea.com/tea/bigelow/earl-grey-decaf/87/) |
| 10:06 |
* kmlussier |
chuckles at the idea of gmcharlt_ drinking decaf anything. |
| 10:16 |
Dyrcona |
Right. I think I'm going to have to start the router with gdb to get a backtrace. I've already built it with -g. |
| 10:29 |
|
Guest17 joined #evergreen |
| 10:30 |
Dyrcona |
I think the crash happens in the child processes. |
| 10:32 |
Dyrcona |
berick: Think I'll 'set fork_follow_mode child' and set a breakpoint on setupRouter. |
| 10:33 |
Dyrcona |
Be funny if it's the "free(pid_file)" just before that. :) |
| 10:35 |
berick |
and now i wanna try my Rust router (w/ redis) on 24.04 |
| 10:35 |
berick |
Dyrcona: what 24.04 are you running? guessing there's a pre-release somewhere |
| 10:36 |
Dyrcona |
I grabbed if from the dailies a few weeks ago and install updates every day. Just a sec, I'll paste the link to the latest preview image. |
| 10:38 |
berick |
oh neat there's an LXC ubuntu-daily image source |
| 10:40 |
Dyrcona |
https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/ |
| 10:40 |
berick |
sudo lxc launch ubuntu-daily:24.04 ... does it |
| 10:40 |
berick |
thanks Dyrcona |
| 10:40 |
Dyrcona |
Ah, cool. I haven't used the lxc images. I still muck about with qemu. |
| 11:05 |
|
collum joined #evergreen |
| 11:22 |
|
collum joined #evergreen |
| 11:32 |
mantis |
We upgraded from 3.9.4 to 3.11.2 a couple of months ago. One library is saying they can't successfully upload a B&T PO through EDI but they are receiving invoices and POs are successful with Midwest. I know there was a fix for Ingram in 3.11.5. Is there a possible bug I'm not aware of relating to this situation? |
| 11:33 |
Bmagic |
mantis: any clues in acq.edi_message ? |
| 11:35 |
mantis |
seeing a lot of processed and a few completes |
| 11:38 |
mantis |
no errors by status |
| 11:38 |
berick |
we upgraded to 3.11 2 days ago... guess i better take a look |
| 11:39 |
mantis |
after filtering in that account ID, it doesn't have any completes |
| 11:40 |
mantis |
just processed |
| 11:40 |
mantis |
EDI message count is 0 on the POs |
| 11:41 |
|
collum joined #evergreen |
| 11:42 |
Bmagic |
For sending* the original activation order, the message_type is "ORDERS", and the acknowledgment is "ORDRSP" |
| 11:43 |
berick |
B&T "ORDERS" messages are working OK here since the 3.11 update |
| 11:43 |
Bmagic |
This should show the pairing for the last week |
| 11:43 |
Bmagic |
select purchase_order,message_type,create_time,status from acq.edi_message where create_time > now() - '1 week'::interval and message_type in('ORDERS','ORDRSP') order by 1,3 |
| 11:44 |
berick |
Bmagic++ # and worth noting ORDRSP seem to stop at "processed" instead of "complete" |
| 11:45 |
Bmagic |
yeah, my database shows the same. Healthy ORDRSP show "processed", healthy ORDERS are "complete" |
| 11:48 |
mantis |
berick++ |
| 11:48 |
mantis |
ok that's what I can say I see, too |
| 11:49 |
Bmagic |
I suppose that query isn't showing the purchase orders from your staff's report? |
| 11:49 |
|
collum joined #evergreen |
| 11:52 |
Bmagic |
try this |
| 11:52 |
Bmagic |
select apo.id,message_type,aem.create_time,status from acq.edi_message aem left join acq.purchase_order apo on(apo.id=aem.purchase_order) where apo.order_date > now() - '1 week'::interval and aem.message_type in('ORDERS','ORDRSP') order by 1,3 |
| 11:54 |
mantis |
looks like for us, if a library isn't using the EDI attributes, it's sending through |
| 11:54 |
mantis |
if it is, those don't come back with EDI messages |
| 11:55 |
Bmagic |
did your upgraded utility server get setup with the ruby edi_webrick code? |
| 11:56 |
mantis |
ah ok |
| 11:56 |
mantis |
I understand now |
| 11:57 |
mantis |
looking throug our logs, we do need to reinstall Evergreen on a particular server to make sure to avoid this issue with the EDI pusher |
| 11:57 |
mantis |
or rather EDI |
| 11:58 |
mantis |
Bmagic++ thank you |
| 11:58 |
Bmagic |
mantis++ |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:01 |
|
stephengwills joined #evergreen |
| 12:23 |
Dyrcona |
mantis: " if a library isn't using the EDI attributes, it's sending through" Are you running edi_pusher.pl or edi_order_pusher.pl Attributes require the latter. |
| 12:52 |
mantis |
Dyrcona: we do have both enabled in cronjobs, but when I did try to run ./edi_order_pusher.pl, it comes up with this error |
| 12:52 |
mantis |
Can't call method "san" on an undefined value at /usr/local/share/perl/5.30.0/OpenILS/Utils/EDIWriter.pm line 151. |
| 12:53 |
Bmagic |
mantis: either the address for the library (in organizational units) is missing it's san, or the vendor is |
| 12:53 |
Dyrcona |
One of the accounts is configured for the wrong org_unit, probably the system. |
| 12:53 |
Dyrcona |
It's almost always the org unit in my experience. |
| 12:54 |
Bmagic |
and the point gets a bit more muddled because we like to setup our purchase orders at the system level, therefore, the system definition in org_unit needs the san. If you're making PO's at the branch level, then the specific branch needs it's san set in org_unit |
| 12:55 |
Bmagic |
though, maybe the code walks up the tree until it finds a san, not sure on that |
| 12:55 |
Dyrcona |
Also, I suggest getting everyone moved to attributes when you can. It will simplify things to only have 1 pusher running. |
| 12:55 |
Dyrcona |
And, no more ruby_webrick. |
| 12:56 |
Bmagic |
Drycona++ # yes! Get rid of the old ruby JEDI code, your life gets easier |
| 12:57 |
mantis |
I can confirm that this problem is happening with a library system level |
| 12:57 |
mantis |
so we don't have addresses inputted there |
| 12:57 |
Bmagic |
that is likely the whole issue |
| 12:57 |
mantis |
however, there aren't any SANs in the branch level |
| 12:57 |
mantis |
and before we upgraded, it was working fine |
| 12:58 |
Bmagic |
Evergreen did* change recently, where it requires that san number to be in the address definition for our org_unit |
| 12:58 |
Bmagic |
I've ran into it a couple of times |
| 12:58 |
mantis |
ok |
| 12:58 |
mantis |
sorry we never had SANs |
| 12:58 |
mantis |
how do I generate that/what is that lol |
| 12:59 |
Bmagic |
Each library using EDI, gets assigned a SAN number, and that's the number that the vendor will be configured to expect. It's a unique identifier for the Evergreen library entity |
| 13:00 |
Bmagic |
Usually the vendor assigns them one.... but when interacting with more than one vendor, the same SAN is reused for all of them right berick? |
| 13:01 |
berick |
there's a buyer SAN -- what this issue relates to -- and a vendor SAN. |
| 13:02 |
mantis |
and we store this in Org Unit Confirguation in the GUI or is there another place? |
| 13:02 |
berick |
they buyer in this case is the library and is typically the same across providers |
| 13:02 |
berick |
mantis: acq provider |
| 13:02 |
mantis |
ok |
| 13:02 |
mantis |
I also see it in actor.org_address |
| 13:03 |
berick |
there is an optional way to override the buyer san via an org address, but .. |
| 13:03 |
berick |
yes |
| 13:03 |
Dyrcona |
The vendor SAN goes in acq.provider. The buyer san in the address. |
| 13:03 |
Bmagic |
thank you, right, you're looking for "buyer" san |
| 13:03 |
berick |
actually, yeah... putting the buyer san in the org unit address is the main approach |
| 13:03 |
berick |
but you can override on a per-vendor basis within the acq provider buyer_san field |
| 13:05 |
Dyrcona |
As for finding out what the SAN should be for a library, I don't know where they come from. Presumably there's an agency handing them out. I'd ask on the openils-acq list. |
| 13:05 |
mantis |
Dyrcona++ |
| 13:10 |
Dyrcona |
Trying to get a backtrace after SIGABRT is hard. |
| 13:11 |
Dyrcona |
bt\n no stack |
| 13:11 |
berick |
hoping to get back to 24.04 shortly |
| 13:12 |
Dyrcona |
Well, I got tired of typing step ... step ... step... so I'm trying to catch the state after signal 6 arrives, but it's not working. |
| 13:13 |
Dyrcona |
Guess, I'm back to setting a breakpoint. |
| 13:14 |
mantis |
does SAN need to be placed in mailing or physical? |
| 13:16 |
berick |
mantis: mailing |
| 13:16 |
berick |
org_unit_san => $po->provider->buyer_san || |
| 13:16 |
berick |
$po->ordering_agency->mailing_address->san || '', |
| 13:16 |
Bmagic |
lol |
| 13:16 |
Bmagic |
I was about to paste that |
| 13:16 |
mantis |
ok I can confirm that's what they'r ein |
| 13:17 |
Dyrcona |
This debugging would be more interesting if I installed the debug versions of stdlib. |
| 13:18 |
Dyrcona |
77in ../sysdeps/x86_64/multiarch/strlen-avx2.S <- Not very inspiring to look at. |
| 13:29 |
Dyrcona |
ooh got something useful that time. It might be blowing up in client_connect |
| 13:31 |
|
kworstell_isl joined #evergreen |
| 13:36 |
Dyrcona |
looks like maybe it's va_list_to_string blowing up on a bad parameter.... |
| 13:37 |
Dyrcona |
I get impatient stepping through the system calls. :) |
| 13:40 |
Dyrcona |
Interesting. It blows up before it gets there. |
| 13:41 |
Dyrcona |
huh. I thought I "set args" |
| 13:44 |
Dyrcona |
I should do this more often. I keep having to look up how to do basic stuff, like show the current variables, etc. |
| 13:47 |
Dyrcona |
So, the crash I'm looking at is something caught by vsnprintf() from a va_list_to_string() triggered from client_connect().... Now, which one? |
| 13:49 |
Dyrcona |
Well, there's only 1 in there. |
| 13:57 |
Dyrcona |
ugh. It doesn't look like anything bad is being passed to va_list_to_string... |
| 13:59 |
|
kworstell_isl_ joined #evergreen |
| 13:59 |
Dyrcona |
Definitely blowing up in va_list_to_string, if I step over it, instead of into it, boom! |
| 14:09 |
Dyrcona |
I think the va_start and va_copy are out of order. I'm going to swap the lines and see what happens. |
| 14:13 |
Dyrcona |
And, no. that's not it or not the only problem. |
| 14:23 |
jeff |
Oh, good. There will be lightning talks at this year's conference. Looks like half of the time is reserved for exhibitors, but looks like conference participants have a half hour set aside on day two. |
| 14:25 |
jeff |
well, Wednesday, which may or may not be considered "day 2", depending on if the pre-conference is day 0 or day 1. ;-) |
| 14:25 |
|
mantis left #evergreen |
| 14:32 |
Dyrcona |
Oh... man... that's a doozy... |
| 14:33 |
Dyrcona |
len is 0 when the final vsprninft is called, so it gets called like this vsprintf(buf, -1, format, a_copy)..... |
| 14:33 |
Dyrcona |
How this ever worked, IDK. |
| 14:36 |
Dyrcona |
vsnprintf (__ap=0x7fffffffdf90, __fmt=0x7ffff7fa2119 "%s@%s/%s", |
| 14:36 |
Dyrcona |
__n=18446744073709551615, __s=0x555555589280 "") |
| 14:36 |
Dyrcona |
Yeahp.... |
| 14:40 |
Dyrcona |
Yeahp.. Fixing that another dbb run is clean: [Inferior 1 (process 120843) exited normally |
| 14:40 |
Dyrcona |
s/dbb/gdb/ |
| 14:41 |
Dyrcona |
This should probably be its own bug. Not sure it's exploitable. |
| 14:52 |
csharp_ |
we're getting slayed by open-ils.actor.get_barcodes requests - looks like a cataloger doing deletes |
| 14:53 |
csharp_ |
I need to look at the parallel-requests bugs for how to fix it |
| 15:08 |
csharp_ |
between the bots and the catalogers, this has been a busy system day |
| 15:32 |
Dyrcona |
csharp_++ |
| 16:03 |
|
jihpringle joined #evergreen |
| 16:12 |
Dyrcona |
Yay! I got 2+2 = 4! :) |
| 16:12 |
Dyrcona |
I'll have to run the other tests later. |
| 17:01 |
|
dmoore joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:23 |
|
jihpringle joined #evergreen |
| 17:58 |
|
jihpringle joined #evergreen |
