| Time |
Nick |
Message |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:46 |
|
agoben joined #evergreen |
| 07:50 |
|
Dyrcona joined #evergreen |
| 08:23 |
|
JBoyer joined #evergreen |
| 08:30 |
Dyrcona |
So, looks like we had memory starvation on one of our bricks because of Apache last night around 10:30 pm EDT. |
| 08:30 |
Dyrcona |
OOM Killer decided to kill beam.smp, 'cause y'know, it's not doing anything. |
| 08:31 |
Dyrcona |
This is with Apache 2.2, btw, so the memory issues are not restricted to Apache 2.4. |
| 08:32 |
Dyrcona |
I'm blaming Apache, because OOM Killer apparently blames apache: |
| 08:32 |
Dyrcona |
Mar 23 22:35:06 bh5 kernel: [2708036.233015] /usr/sbin/apach invoked oom-killer: |
| 08:33 |
* Dyrcona |
looks for the Lp bug. |
| 08:34 |
JBoyer |
Dyrcona, as far as I understand it, doesn't the OOM killer just take out whatever requested ram when there's no more to go around? |
| 08:35 |
Dyrcona |
JBoyer as for it what it kills, it's more complicated than that, as for that long line, yes. |
| 08:36 |
Dyrcona |
Unfortunately, I can't go back and look at the state of the system, though the kern.log is filled with lines of numbers about the state of all the processes at the time. |
| 08:36 |
Dyrcona |
I'll have to find out what each position means. |
| 08:36 |
Dyrcona |
But, I'm still blaming apache because I've seen this before at MVLC, with 2.2 and 2.4. |
| 08:37 |
Dyrcona |
And, I thought someone made a bug about Apache consuming a lot of RAM? |
| 08:37 |
JBoyer |
Makes sense, I've not looked into it in ages. Good luck with the sleuthing. |
| 08:38 |
JBoyer |
And re: apache and ram, isn't it (a LOT) more likely that our perl modules loaded into every apache instance are chewing up the ram? Might make finding (or reporting it) in LP difficult. |
| 08:38 |
Dyrcona |
Lp 690910: A trip down Memory Dirty Back Alley. |
| 08:39 |
pinesol_green |
Launchpad bug 690910 in Evergreen "Apache process spin out of control" [Undecided,Incomplete] https://launchpad.net/bugs/690910 |
| 08:39 |
Dyrcona |
JBoyer: Yes, I believe it is the Perl code that is ultimately responsible. |
| 08:39 |
Dyrcona |
Possibly, Perl itself. |
| 08:40 |
Dyrcona |
I need to do some more testing, but something changes from Perl 5.14 (maybe 5.18) to Perl 5.20 that make DBD::Pg and DBI behave "differently." |
| 08:41 |
Dyrcona |
Of course, this happened on Debian 7 with Perl 5.14 and Apache 2.2, so that wouldn't be the issue here. |
| 08:41 |
Dyrcona |
But, still, if someone did a search that tries to return every record.... |
| 08:48 |
|
mdriscoll joined #evergreen |
| 09:05 |
|
kmlussier joined #evergreen |
| 09:29 |
|
yboston joined #evergreen |
| 09:37 |
* kmlussier |
stumbles across an old message sent to the list where we reached consensus on removing something, but then never followed through on the removal. http://georgialibraries.markmail.org/thread/6tt76qaptx7lufk5 |
| 09:38 |
kmlussier |
I'll add it to my to-do list for things I can do after the conference when I should have loads of time on my hands. |
| 09:41 |
|
maryj joined #evergreen |
| 09:41 |
|
maryj_ joined #evergreen |
| 09:42 |
Dyrcona |
If I had a nickel for every time that happened.... Well, I'd have almost a dollar... :) |
| 09:46 |
kmlussier |
Dyrcona: Yeah, but I feel bad because following up on that consensus wouldn't have taken more than 15 minutes. |
| 09:48 |
Dyrcona |
That's often the case, too. :) |
| 09:48 |
Dyrcona |
We decide to do something as a group, but don't single out someone to actually do it. |
| 09:49 |
Dyrcona |
Happens a lot, in general, not just here. |
| 09:50 |
gmcharlt |
a new project role? Tidier of Loose Ends? |
| 09:50 |
* gmcharlt |
is not entirely joking |
| 09:57 |
Dyrcona |
Not me. My ends are all loose. |
| 10:00 |
|
jvwoolf joined #evergreen |
| 11:25 |
|
Christineb joined #evergreen |
| 11:32 |
kmlussier |
@who is the biggest procrastinator in the Evergreen community? |
| 11:32 |
pinesol_green |
csharp is the biggest procrastinator in the Evergreen community. |
| 11:32 |
kmlussier |
Nope, pinesol_green, I'm pretty sure it's me. |
| 11:38 |
Dyrcona |
So, someone managed to place 3 holds in a row for the same patron for the same bib, and they're surprised that all 3 have the same copy targeted. |
| 11:38 |
* Dyrcona |
isn't. |
| 11:38 |
Dyrcona |
You're not supposed to do that, yet. |
| 11:39 |
Dyrcona |
Too bad there's no close option for "you're doing it wrong." |
| 11:41 |
csharp |
@blame pinesol_green for picking me |
| 11:41 |
pinesol_green |
csharp: itself HAXORED csharp's SERVERZ!!!! for picking csharp |
| 11:42 |
Dyrcona |
I'll bet that if they fill one of the holds, the others will get retargeted eventually. |
| 11:42 |
Dyrcona |
@blame me for everything! |
| 11:42 |
pinesol_green |
Dyrcona: I come to bury Dyrcona, not to praise them. for everything! |
| 11:42 |
Dyrcona |
bah. That one stinks... Who added it? :) |
| 11:42 |
* Dyrcona |
did. |
| 11:43 |
Dyrcona |
@blame me again |
| 11:43 |
pinesol_green |
Dyrcona: Dyrcona again is why we can never have nice things! |
| 11:43 |
gmcharlt |
@praise Dyrcona |
| 11:43 |
* pinesol_green |
the upgrade came off brilliantly, and it's all because of Dyrcona |
| 11:43 |
csharp |
okay, can someone confirm that the "magical statuses" capability (that blocks catalogers from being able to set copies to certain statuses) is gone in the web client |
| 11:43 |
kmlussier |
Dyrcona: That's interesting and something that should be accounted for in my requirements. |
| 11:43 |
csharp |
? |
| 11:44 |
kmlussier |
csharp: I can confirm. |
| 11:44 |
kmlussier |
There's a bug for that. |
| 11:44 |
csharp |
oh good |
| 11:44 |
kmlussier |
It might be one that I even highlighted in one of those e-mails I sent out to the list. |
| 11:44 |
csharp |
I was looking at bug 1616170 and wanting to confirm that aspect in the new client |
| 11:44 |
pinesol_green |
Launchpad bug 1616170 in Evergreen "Not possible to create copy status without manual code changes" [Medium,New] https://launchpad.net/bugs/1616170 |
| 11:45 |
kmlussier |
csharp: Actually, the bug is a general magical statuses bug. I'm thinking the web client piece should be its own bug. |
| 11:45 |
kmlussier |
bug 1616980 |
| 11:45 |
pinesol_green |
Launchpad bug 1616980 in Evergreen "Magical statuses not so magical - possible for staff to edit items into or out of magical statuses" [Undecided,New] https://launchpad.net/bugs/1616980 |
| 11:46 |
* Dyrcona |
is also having "fun" with libvirt and host shares. |
| 11:46 |
Dyrcona |
Apparently, making them writable and ownable by someone other than root, postgres say, on the guest is a lot harder than it looks. |
| 11:46 |
csharp |
kmlussier: I agree that the web client piece should be its own bug |
| 11:47 |
csharp |
Dyrcona: yeah - we ended up hard-coding uids to solve our NFS woes |
| 11:47 |
Dyrcona |
csharp: Not NFS. NFS is easy by comparison. |
| 11:48 |
Dyrcona |
This is 9p virtio. |
| 11:49 |
csharp |
Dyrcona: ah |
| 11:50 |
Dyrcona |
I hard coded uids for opensrf for NFS, no big deal. |
| 11:50 |
csharp |
kmlussier: I'm experimenting with adding new attributes to the config.copy_status table that would control how they are edited/circulated |
| 11:50 |
Dyrcona |
So, I'll make a 900GB file on the host partition. |
| 11:54 |
miker |
Dyrcona / csharp: y u no like NIS+? :) |
| 11:54 |
Dyrcona |
:) |
| 11:54 |
Dyrcona |
I tried that once, 15+ years ago....not going back. |
| 11:55 |
Dyrcona |
yppasswd opensrf .... |
| 11:55 |
Dyrcona |
Oops.. wrong window :) |
| 11:56 |
Dyrcona |
This'll be fun...testing a db upgrade in a file image on a USB drive.... |
| 11:57 |
Dyrcona |
<spongebob_depressed_announcer_voice>Two months later....</spongebob_depressed_announcer_voice> |
| 11:57 |
jeff |
hah. mostly-quiescent non-production database, ran a vacuum full analyze on it earlier today. shrunk by a few gigs, as you might expect for something that hadn't been vacuumed in a bit and had a bunch of data shuffled around within it. |
| 11:57 |
jeff |
the "hah" was because i just noticed that it grew by a megabyte since then. :-) |
| 11:58 |
Dyrcona |
Well, this'll be a pg_upgrade test with production data, freshly restored, so it'll be small as possible. |
| 11:58 |
Dyrcona |
I tried before with a 600GB image file. It was too smal. |
| 11:59 |
Dyrcona |
The missing 'l' is somehow appropriate. |
| 12:03 |
|
jvwoolf joined #evergreen |
| 12:19 |
|
jihpringle joined #evergreen |
| 12:20 |
csharp |
my bug and mmorgan's bug were filed two days apart and are *almost* duplicates |
| 12:20 |
|
Dyrcona left #evergreen |
| 12:20 |
|
Dyrcona joined #evergreen |
| 12:34 |
StomproJ |
Can anyone explain entries with negative ID numbers is actor.usr_address? Are those copies of the original entry? |
| 12:36 |
jeff |
StomproJ: in the user editor, some addresses that haven't yet been saved have an ID of -1 or such, which can present itself when you use (at least the dojo) editor and delete an address on a brand new unsaved user. |
| 12:36 |
jeff |
StomproJ: i don't have any values <=0 for actor.usr_address.id in our system, though. |
| 12:37 |
csharp |
StomproJ: we don't have any <=0 either, FYI |
| 12:37 |
berick |
i seem to recall it has something to do with pending addresses.. |
| 12:38 |
StomproJ |
Hmm, thanks, we have 149 of them right now for some reason. |
| 12:38 |
Dyrcona |
Do you have online user registration? |
| 12:38 |
jeff |
It's possible that some scenarios create them, but first things that come to mind for me are migration, a manual cleanup query, or a less-used feature like pending addresses. |
| 12:39 |
Dyrcona |
I'm not sure that does it, but "pending addresses" made me think of it. |
| 12:40 |
StomproJ |
Thanks, they probably are left over from migration staging. |
| 12:41 |
jeff |
nope, it's pending addresses. |
| 12:41 |
jeff |
the actor.approve_pending_address database function flips the replaced address to be a negative of its original id. |
| 12:42 |
jeff |
the address with pending=true and replaces=some_id gets to become that address id, and the existing address gets its id changed to the negative. |
| 12:43 |
jeff |
and if an address is replaced more than once, the already-existing negative id (already replaced) address is deleted. |
| 12:43 |
StomproJ |
jeff++ thank you for figuring that out. |
| 12:44 |
jeff |
berick++ because i wouldn't have bothered to look unless he had also had the same thought :-) |
| 13:11 |
csharp |
jeff++ |
| 14:01 |
|
Jillianne joined #evergreen |
| 14:42 |
* kmlussier |
thinks the issue Stuart has is something that occurred with a staff person here, but can't remember how we resolved it. |
| 14:45 |
kmlussier |
Does anyone know if anybody archived the tweets from the last conference? |
| 14:48 |
* kmlussier |
reminds rhamby of a comment he made here http://georgialibraries.markmail.org/thread/zygg27pe7ir66ref |
| 14:49 |
gmcharlt |
kmlussier: as it happens... I did! |
| 14:49 |
gmcharlt |
(and then completely forgot about it) |
| 14:50 |
kmlussier |
Yes, I just found that email! But it doesn't say where to find it. :) |
| 14:50 |
kmlussier |
gmcharlt++ |
| 14:51 |
kmlussier |
If I don't have tweets to refresh my memory, I fear the conference recap in the annual report will just be a recap of my terribly delayed train trip to get there. |
| 14:52 |
rhamby |
kmlussier: tweets are mostly still in existence with the #evgils16 hashtag |
| 14:52 |
rhamby |
I know becuase I went looking through them for pics last night |
| 14:53 |
kmlussier |
rhamby: So they are! For some reason, I tried searching the hashtag on Google, which only retrieved one lone tweet from gmcharlt |
| 14:53 |
rhamby |
Google loves gmcharlt, hates the rest of us. |
| 14:54 |
rhamby |
I said it on the internet so now it's true. |
| 14:54 |
kmlussier |
@eightball does Google really love gmcharlt? |
| 14:54 |
pinesol_green |
kmlussier: Naturally. |
| 14:54 |
kmlussier |
pinesol_green confirmed it, so it really must be true. |
| 14:54 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 14:54 |
pinesol_green |
kmlussier: http://wonder-tonic.com/geocitiesizer/content.php?theme=2&music=6&url=evergreen-ils.org |
| 14:55 |
kmlussier |
rhamby: But I like the idea of incorporating some tweets in our conference recap. I'll screenshot some of them. |
| 14:55 |
rhamby |
kmlussier: agreed |
| 14:58 |
gmcharlt |
kmlussier: I'll put it in a permanent home later, but for now: http://zadi.librarypolice.com/~gmc/evgils16/evgils16.html |
| 14:58 |
gmcharlt |
also, all I'll say is this... Google and I have... come to an arrangement |
| 14:59 |
* gmcharlt |
giggles |
| 14:59 |
gmcharlt |
https://twitter.com/roganhamby/status/722805148368683008 |
| 14:59 |
gmcharlt |
rhamby: your facial express makes that pic |
| 15:00 |
rhamby |
gmcharlt: I have really debated finding a place for that in the report because I like it but have worried it would be too self serving |
| 15:00 |
rhamby |
which isn't to say I won't do it ...... |
| 15:05 |
kmlussier |
I missed a lot of these tweets the first time around. |
| 15:41 |
|
kipd joined #evergreen |
| 16:35 |
jeffdavis |
hm, I'm getting an error in the web client when I should get an opt-in dialog |
| 16:35 |
jeffdavis |
2.12 beta, still need to test on 2.12.0 |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
remingtron joined #evergreen |
| 20:42 |
|
jvwoolf joined #evergreen |
| 21:10 |
|
jihpringle_ joined #evergreen |
