| Time |
Nick |
Message |
| 07:30 |
|
kworstell-isl joined #evergreen |
| 07:34 |
|
redavis joined #evergreen |
| 07:55 |
|
cbrown joined #evergreen |
| 08:06 |
|
BDorsey joined #evergreen |
| 08:33 |
|
dguarrac joined #evergreen |
| 09:08 |
|
Dyrcona joined #evergreen |
| 09:11 |
Bmagic |
berick: good news, it segfaulted last night |
| 09:13 |
Bmagic |
gdb is attached to both routers in a screen. But I'm not sure what to do next |
| 09:15 |
Dyrcona |
What is segfaulting? Redis? A router? A drone? |
| 09:39 |
Bmagic |
opensrf_router (same as what we're tracking down with gdb) |
| 09:40 |
Bmagic |
[Nov22 00:14] opensrf_router[2423835]: segfault at 7ffddc04c898 ip 00007c808a1 |
| 09:40 |
Bmagic |
pastebin from yesterday https://pastebin.com/YVizyW7Q |
| 09:45 |
Dyrcona |
Error 6 is an attempt to write to unmapped memory. It's the classic dereference of a null or uninitialized pointer. |
| 09:47 |
Dyrcona |
You rebuilt OpenSRF/Evergreen with debug options? If not, using gdb isn't going to help much. |
| 09:49 |
berick |
Bmagic: can you enter 'bt' to get the backtrace? |
| 09:54 |
berick |
to clarify, one of the gdb windows should indicate a failure and provide some basic info, then typing 'bt' will present additional info |
| 10:04 |
|
BDorsey_ joined #evergreen |
| 10:17 |
Bmagic |
in the gdb cli? |
| 10:19 |
berick |
yes |
| 10:19 |
Bmagic |
typing bt into the CLI causes it to hang for a minute, then return. No output |
| 10:19 |
berick |
was there an indication of failure in the CLI? |
| 10:20 |
Bmagic |
no |
| 10:20 |
berick |
neither of them? |
| 10:20 |
Bmagic |
nope |
| 10:20 |
Bmagic |
I was thinking that might be the case. Docker is mucking the works up |
| 10:21 |
Bmagic |
when I look at dmesg on the host machine, I get a report when gdb was invoked on the guest container. And according to the host, it was attached to process ID 1 |
| 10:21 |
berick |
well double-dang |
| 10:22 |
Bmagic |
[Nov21 12:38] ptrace attach of "while true; do sleep 1; done"[1348811] was attempted by "gdb /openils/bin/opensrf_router 1"[1479177] |
| 10:23 |
berick |
freaky |
| 10:24 |
Bmagic |
that "while true" stuff is my container's ENTRYPOINT, so I recognize that |
| 10:24 |
berick |
yeah, seemed familiar |
| 10:25 |
Bmagic |
I'll get this rig setup on a bare VM |
| 10:25 |
berick |
Bmagic++ |
| 10:29 |
Bmagic |
we'll probably find out that it won't fail in that environment |
| 10:32 |
Dyrcona |
The bt won't be that useful if you don't compile with debug options. I think you can do that through configure. |
| 10:43 |
Bmagic |
Dyrcona: hmmm, well, I had better do that when I install on this new machine |
| 10:44 |
Bmagic |
what's the switch? |
| 10:46 |
berick |
fwiw, i've never had to do that. it usually just works. *shrug* |
| 11:09 |
Bmagic |
I'll build like normal then |
| 11:28 |
|
BDorsey joined #evergreen |
| 11:57 |
Rogan |
question for the crowd, is anyone else seeing issues when retargeting local holds as a check in modifier, it failing because of a large number of holds? |
| 12:00 |
Bmagic |
Rogan: I've not seen any tickets related to that (yet) |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:17 |
Dyrcona |
Bmagic: --enable-debug |
| 12:35 |
|
kmlussier joined #evergreen |
| 12:53 |
|
Christineb joined #evergreen |
| 12:54 |
eeevil |
Rogan: IIRC, I've heard whisperings of a new-targeter bug where it doesn't restrict itself to "local" holds, and times out because it's trying to retarget /all/ holds that the item's bib might be involved in ... |
| 12:54 |
Rogan |
eeevil hmmmm |
| 12:56 |
Rogan |
not on launchpad yet I assume, or if it is my search fu failed me this morning |
| 12:57 |
eeevil |
yeah, I don't think it's made it to LP yet :( ... I don't have more details, either |
| 13:39 |
|
ianskelskey joined #evergreen |
| 13:44 |
ianskelskey |
Hey ya'll we're considering making more use of the booking module at Bibliomation. I was curious how other people are using it. Can anyone provide examples of clever applications? |
| 13:49 |
Dyrcona |
ianskelskey: You might get more traction on the general mailing list than in IRC. |
| 13:54 |
ianskelskey |
I'll try that too. Thank you! |
| 14:01 |
|
kmlussier1 joined #evergreen |
| 14:01 |
|
kmlussier1 left #evergreen |
| 14:03 |
csharp_ |
berick: Redis on non-localhost configs question: how do you configure the bind address(es) at the Redis level? the default 127.0.0.1 ::1 config didn't allow connections so I removed the bind directive and set protected mode to off (which sounds Bad™ to me) |
| 14:03 |
csharp_ |
it now connects though |
| 14:03 |
csharp_ |
this is not a server directly visible on the web, but I don't want to be incautions |
| 14:03 |
csharp_ |
incautious, even |
| 14:04 |
Dyrcona |
csharp_: I assume your machine has a local IP address? Can't you just bind to that one? |
| 14:05 |
csharp_ |
yeah, was about to try that approach |
| 14:07 |
csharp_ |
that appears to be working with protected mode on |
| 14:07 |
csharp_ |
osrf_control is hanging on at least one of the services |
| 14:07 |
csharp_ |
but I don't think that's related to the connection refused problem |
| 14:10 |
Dyrcona |
Are you trying to run redis on machine a and run some drones/listeners on machine b? |
| 14:14 |
berick |
yeah, just bind to your specific IP |
| 14:17 |
csharp_ |
thanks |
| 14:17 |
csharp_ |
Dyrcona: just one machine - self contained app brick |
| 14:18 |
Dyrcona |
ok. sounded to me like you might be trying a more complicated setup. |
| 14:19 |
csharp_ |
trying to keep it simple! |
| 14:19 |
csharp_ |
however, the router doesn't want to start |
| 14:19 |
berick |
yeah why non-localhost for a self-contained setup? |
| 14:19 |
csharp_ |
well, it's within a cluster |
| 14:20 |
csharp_ |
for ejabberd we used FQDN |
| 14:20 |
csharp_ |
working from existing configs |
| 14:20 |
berick |
i see |
| 14:21 |
csharp_ |
so for your app servers in production are they each using localhost config? |
| 14:21 |
csharp_ |
(at the redis config level?) |
| 14:22 |
berick |
yeah. so.. cross-brick talk w/ redis works fine, but once the last Dojo interface is gone, it's no longer necessary, unless you want a full mesh-style high-availability setup |
| 14:22 |
berick |
all localhost here |
| 14:22 |
csharp_ |
ok - that's interesting... |
| 14:23 |
berick |
the old http-translator is the only thing that requires cross talk like that, because stateless http |
| 14:23 |
berick |
and even then, only for dojo UI's that do connected sessions, which was primarily the old admin UIs |
| 14:23 |
berick |
it's had zero impact here |
| 14:24 |
csharp_ |
well it's certainly easier to do |
| 14:24 |
Dyrcona |
Isn't the old http-translator gone? |
| 14:24 |
berick |
still there |
| 14:24 |
berick |
Dyrcona: you may be thinking of the old style JSON we removed from the gateway |
| 14:24 |
csharp_ |
still translating, I guess |
| 14:25 |
csharp_ |
trying to keep up with new technologies to stay relevant |
| 14:25 |
* csharp_ |
can relate |
| 14:25 |
* csharp_ |
shakes cane at youngsters in hoodies |
| 14:26 |
Dyrcona |
Yeah. That's it. |
| 14:41 |
|
jihpringle joined #evergreen |
| 14:50 |
|
kmlussier joined #evergreen |
| 15:05 |
Bmagic |
berick: ok, got a new machine up, and gdb going on the two routers. But I've noticed that as soon as I attach to the router processes on this machine, Evergreen is broken. It seems it's pausing the process somehow |
| 15:05 |
berick |
are you doing 'continue' ? |
| 15:06 |
Bmagic |
hmm, nope |
| 15:06 |
Bmagic |
that did it |
| 15:06 |
Bmagic |
ok, I'm set |
| 15:07 |
Bmagic |
attacking... |
| 15:07 |
berick |
awesome |
| 15:18 |
|
abowling joined #evergreen |
| 15:21 |
abowling |
Anyone run into this? |
| 15:21 |
abowling |
raw_transport: LOGIN ERROR: 'Failed to load ILS implementation 'OpenILS::SIP' at Sip/MsgType.pm line 918 |
| 15:22 |
berick |
abowling: maybe try: perl -MOpenILS::SIP |
| 15:26 |
Dyrcona |
I would think if that's failing, the rest of Evergreen would fail, too. |
| 15:28 |
Bmagic |
berick: I'll probably end up having to check back on this after it runs in the night. I just ran it (action_trigger_runner) by hand and everything was hunky dory |
| 15:28 |
abowling |
berick++ |
| 15:28 |
berick |
Bmagic: *nod* |
| 15:28 |
abowling |
missing |
| 15:31 |
Dyrcona |
abowling: What about perl -MOpenILS ? |
| 15:36 |
csharp_ |
abowling: if it's an upgraded server it might be running into a path issue - I remember something about relative path not working after a particular Perl point upgrade |
| 16:34 |
abowling |
getting the ejabberd not connected to the network. ubuntu 20.04. ejabberd is disabled in apparmor. passwords are most certainly correct. anyone run into this? |
| 16:36 |
Dyrcona |
abowling: what does `sudo systemctl status ejabberd.service` say? |
| 16:36 |
abowling |
Dyrcona: it's running |
| 16:37 |
Dyrcona |
I'd double check that the passwords are correct. |
| 16:41 |
Dyrcona |
I'd check that the ejabberd.yml file is correct per our instructions. I forgot to change the password format recently and OpenSRF couldn't connect to ejabberd. |
| 17:07 |
|
kmlussier left #evergreen |
| 17:09 |
|
ianskelskey joined #evergreen |
| 20:52 |
pinesol |
News from commits: [Docs] Fixing links that are referenced in the docs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6144d03b803b735a1ec0a8132a403c2b23bb7b69> |
