| Time |
Nick |
Message |
| 07:28 |
|
gsams joined #evergreen |
| 07:33 |
|
collum joined #evergreen |
| 07:59 |
|
JBoyer joined #evergreen |
| 08:13 |
jeff |
good morning, #evergreen |
| 08:38 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:52 |
|
jwoodard joined #evergreen |
| 08:56 |
|
mrpeters joined #evergreen |
| 09:00 |
|
mmorgan1 joined #evergreen |
| 09:03 |
|
mmorgan joined #evergreen |
| 09:11 |
* tsbere |
returns from vacation and is amazed that IRC didn't disconnect, changing his nick and killing his away message |
| 09:16 |
|
bos20k joined #evergreen |
| 09:18 |
|
yboston joined #evergreen |
| 09:27 |
|
kmlussier joined #evergreen |
| 09:29 |
|
terran joined #evergreen |
| 09:29 |
|
maryj joined #evergreen |
| 09:30 |
|
rlefaive joined #evergreen |
| 09:34 |
|
remingtron joined #evergreen |
| 09:56 |
|
mmorgan1 joined #evergreen |
| 10:16 |
Dyrcona |
Doing a build from git this morning and I'm being asked which version of Angular.JS to install. |
| 10:16 |
Dyrcona |
I got similar results when testing the make_release script yesterday. |
| 10:16 |
Dyrcona |
I wonder if we should update the README? |
| 10:17 |
Dyrcona |
Hmm.... Wonder what happens if I install from a tarball. I should test that. |
| 10:24 |
|
maryj joined #evergreen |
| 10:26 |
|
Christineb joined #evergreen |
| 10:36 |
|
abowling joined #evergreen |
| 10:40 |
Dyrcona |
Hmm... Didn't ask this time when making the tarball. I'll see what happens when I install it. |
| 10:41 |
berick |
i would epxect a release tarball to be using an older version of angular, since 1.5 is master only (iirc) |
| 10:41 |
Dyrcona |
Oh, yes, so it is. |
| 10:41 |
|
krvmga joined #evergreen |
| 10:41 |
Dyrcona |
I should make a tarball from master. |
| 10:43 |
Dyrcona |
Might as well install what I've made and then do an upgrade from that. |
| 10:48 |
* jeff |
revises and augments his vendor inquiry from yesterday and hits send |
| 10:49 |
jeff |
we'd like 64/AF displayed whenever present, but so far I can only get the current generation of their software to display it when 64/BL=N (invalid patron) |
| 10:50 |
* tsbere |
wonders what jeff is up to |
| 10:51 |
jeff |
previous generation at least displayed 64/AF (screen message) when present, even if BL=Y (valid patron), though it might have only appeared when something in the patron status fixed field indicated a block (like "charge privileges denied"). |
| 10:52 |
jeff |
we made use of this for things like: |
| 10:52 |
jeff |
return 'Our records show that we need to update or verify your account information. Please visit the circulation desk.' if CORE::time > $expire->epoch; |
| 10:52 |
jeff |
instead of the message just saying "blocked". |
| 10:53 |
jeff |
and i'd like 64/AF to display whenever present, so that we could use it for things like "You have 3 MeLCat holds waiting behind the desk. Please ask a staff member for assistance.", etc. |
| 10:54 |
jeff |
I could even see potential for future integration with the "message center" bits in Evergreen. |
| 10:55 |
jeff |
To return to the original situation where we had a friendly message when the patron was expired, I can have certain SIP2 clients get BL=N with an appropriate AF value for expired patrons, since they can't do much on a self checkout terminal when expired anyway. |
| 10:56 |
Dyrcona |
Yeah, makes sense. |
| 10:56 |
jeff |
But we have other SIP2 clients for things like PC Reservation where not all locations treat expired cards the same, so forcing BL=N for expired patrons on those SIP2 clients would be a bad idea. |
| 10:56 |
Dyrcona |
But different vendors do different things.... |
| 10:57 |
jeff |
And different versions do different things... |
| 10:57 |
jeff |
etc. |
| 10:57 |
Dyrcona |
yep. |
| 10:57 |
jeff |
I started writing some general SIP2 live tests over the weekend. |
| 10:58 |
|
terran joined #evergreen |
| 11:02 |
Dyrcona |
bower resolution Unsuitable resolution declared for angular: 1.5.5 |
| 11:02 |
Dyrcona |
'Cause 1.5.6 is all it can apparently find. |
| 11:03 |
berick |
guess we need to upate the bower json |
| 11:04 |
Dyrcona |
Could be. The 5 options point to 1.4.4 or 1.5.6, and 1.5.6 is required by certain packages. |
| 11:04 |
berick |
i bet there's a way to make it less specific.. like 1.5.* |
| 11:04 |
berick |
or some such |
| 11:06 |
berick |
ah, or just remove the "resolutions" line from bower.json |
| 11:25 |
Dyrcona |
berick: bshum sent me this link: http://stackoverflow.com/questions/19030170/what-is-the-bower-version-syntax |
| 11:26 |
berick |
Dyrcona: very handy, thanks |
| 11:27 |
|
mmorgan joined #evergreen |
| 11:29 |
|
abowling1 joined #evergreen |
| 11:34 |
jeff |
Configuring Windows updates / 100% complete / Do not turn off your computer. |
| 11:35 |
berick |
There will be consequences / Believe Me |
| 11:36 |
jeff |
configuring patch / one hundred precent complete / wait, there is one more |
| 11:36 |
jeff |
bah, s/precent/percent/ |
| 11:42 |
JBoyer |
You say / the size of my updates is not a size you're willing to pay / insane / You cheat with the snap-in, now I'm fighting with oudated revisions / Something something, this sounded much easier before I tried it... Da da da dat da da dat da da da... |
| 11:42 |
jeff |
JBoyer++ |
| 11:43 |
jeff |
though i can't say that i still recognize the source inspiration. |
| 11:44 |
JBoyer |
What Comes Next? from the Hamilton soundtrack. |
| 11:45 |
jeff |
ah! |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:15 |
csharp |
so we're seeing system slowness in PINES, but it doesn't appear to be related to the DB this time around |
| 12:15 |
csharp |
high load on the apache/opensrf servers (no head/drone structure, just single boxes) |
| 12:16 |
csharp |
but the logs aren't crazy - not many NOT CONNECTED TO THE NETWORK!!! messages, no dropped session messages like when the DB's connection pool is full |
| 12:17 |
csharp |
I'm waiting for pgbadger to process the last hour's data, but I'm thinking it's something in the EG layer |
| 12:17 |
csharp |
apache process count got pretty high |
| 12:17 |
csharp |
(talking out loud here in case it sounds familiar to others) |
| 12:18 |
csharp |
it takes 90 to 120 seconds to log into the staff client |
| 12:18 |
|
brahmina joined #evergreen |
| 12:18 |
csharp |
actually moving a bit faster now |
| 12:20 |
csharp |
(but still like a minute) |
| 12:20 |
terran |
csharp++ for working on what was supposed to be his vacation day |
| 12:20 |
csharp |
terran: thanks :-) |
| 12:21 |
* csharp |
should know better than to plan vacations around long weekends |
| 12:27 |
JBoyer |
csharp, sounds like something I'm seeing since the combo U 12.04 -> 14.04 and Eg 2.7 -> 2.9 upgrade. (So, of course, I can't tell which is at fault.) |
| 12:28 |
csharp |
JBoyer: good to know |
| 12:28 |
JBoyer |
Seems to be better on my "new" VM host though, old VMs have 4 cores and 12 GB of RAM, new ones have 8 cores and 32GB of RAM. |
| 12:28 |
csharp |
I was wondering if it's a 14.04 issue |
| 12:29 |
|
bmills joined #evergreen |
| 12:29 |
JBoyer |
or hosting the VMs on 14.04 vs 12.04, lots of variables. :( |
| 12:29 |
csharp |
I will *never* upgrade more than one piece of the OS/DB/EG combo at one time again |
| 12:30 |
jeff |
baby steps to the door, baby steps to 16.04... |
| 12:30 |
JBoyer |
Of course, I'm mostly running 5-7 year old VM hosts, so I'm not saying it's not time to replace some of it. |
| 12:30 |
csharp |
JBoyer: if it helps you, we moved to 14.04 VM hosts before this issue emerged, so that can probably be safely ruled out |
| 12:30 |
jeff |
though perhaps i should have said "baby steps to 2.10.4", since we're not an ubuntu shop... |
| 12:30 |
JBoyer |
That is good to know. |
| 12:31 |
csharp |
and our hardware is of a similar vintage - HP Proliant DL585s |
| 12:31 |
csharp |
G7, I think |
| 12:31 |
csharp |
purchased in 2011 |
| 12:31 |
JBoyer |
Ours are G5. They need to be cranked to start and have walkers. |
| 12:31 |
csharp |
heh |
| 12:31 |
csharp |
I have a couple of G5s as test servers |
| 12:38 |
JBoyer |
So, I have one machine with a normalized load of 1+ (1 min load => # of CPUs) and the top 2 processes by CPU use are apache. pid 24110 has 2 connections to memcache and 2 connections to beam.smp (ejabberd) (which is of course, connected to everything.) |
| 12:40 |
JBoyer |
Oh yes, and no connections to the outside world. just those 4: 2 internal to ejabberd, 2 to the memcache server. |
| 12:41 |
JBoyer |
It's super fun to try to figure out. |
| 12:41 |
berick |
the 2 per ejabberd and memcache are one for C and one for Perl |
| 12:42 |
JBoyer |
But with no other connections is it just sitting there spinning? |
| 12:43 |
JBoyer |
Well, I suppose once it hits beam.smp it could be going literally anywhere, but apache -> opensrf -> apache doesn't sound like a likely software path. |
| 12:44 |
berick |
I've seen apaches spin when their ejabberd socket is disconnected |
| 12:44 |
berick |
strace might help there |
| 12:45 |
* Dyrcona |
has seen that, too. |
| 12:45 |
JBoyer |
Wouldn't that lead to "NOT CONNECTED..." errors being logged, though? |
| 12:46 |
JBoyer |
because these do eventually clear up on their own, obnoxious as it is. |
| 12:46 |
berick |
hm, that's different. the cases I've seen had to be manually killed and no logging occured presuambly because it was stuck in a tight loop. |
| 12:47 |
berick |
haven't seen those lately, though |
| 12:47 |
berick |
various improvements to the osrf code seemed to have helped w/ thsoe |
| 12:47 |
berick |
those |
| 12:47 |
tsbere |
When I see ejabberd disconnects the things that are no longer connected seem to get stuck in a "is there anything to get? No? repeat" loop |
| 12:47 |
JBoyer |
Well, that is to say I certainly don't remember a lot of those errors, but I'll be damned if there aren't plenty now. That's spectacular. |
| 12:47 |
tsbere |
Until an *outgoing* message is attempted they don't notice |
| 12:48 |
* Dyrcona |
did a test upgrade from 12.04 to 14.04 in 2014, but doesn't remember what issues (if any) cropped up. |
| 12:49 |
JBoyer |
I'm wondering if it's a combination of Eg 2.9 and our VM setup. We don't get near running out of memory, which is what I would wonder about first. :( |
| 12:49 |
Dyrcona |
JBoyer: You said you upgraded both the O/S and Evergreen/OpenSRF at the same time? |
| 12:50 |
jeff |
semi-related: i have a test instance (pretty much self-contained) where depending on which apache child my incoming connection hits, i get dead air. |
| 12:50 |
jeff |
i have a (not very helpful) strace. the test instance sits idle for long times. |
| 12:50 |
JBoyer |
Yes. Minimal downtime and all of that. I've made better decisions. |
| 12:51 |
Dyrcona |
jeff: I saw something like that this morning after a fresh install, but without running autogen.sh. |
| 12:51 |
Dyrcona |
After running autogen.sh, Apache and the OPAC seemed happy. |
| 12:51 |
jeff |
Dyrcona: it happened sometimes but not other times, and seeed to only affect certain apache children? |
| 12:52 |
JBoyer |
Aha. strace informs me that this process is calling gethostname for itself, then timing out on select(). Great, great. |
| 12:52 |
Dyrcona |
jeff: I didn't look into that deeply. I realized that I hadn't run autogen.sh, did so, reloaded the page, and presto! |
| 12:52 |
jeff |
ah |
| 12:52 |
JBoyer |
I have a script to restart each app server in turn, for this very reason. :-/ |
| 12:54 |
JBoyer |
berick++ # I'll be using that a lot, hopefully for less aggrivating reasons in the future. |
| 12:56 |
jeff |
JBoyer: using what? strace? |
| 12:56 |
JBoyer |
huuuhh. stracing the particular ejabberd pid only gives me this: select(0, NULL, NULL, NULL, NULL |
| 12:56 |
JBoyer |
As in just that partial line, and sits forever. |
| 12:58 |
Dyrcona |
Um, that's a complete call to select, minus the closing paren, and it basically does nothing, but possibly hang. |
| 12:58 |
Dyrcona |
I seem to recall issues with ejabberd after a 12.04 to 14.04 upgrade, but I could be mistaken. |
| 12:59 |
JBoyer |
strace normally includes the closing paren, that's why I assumed it was partial. |
| 12:59 |
Dyrcona |
JBoyer: If you have a way of testing on a single brick, you could try removing ejabberd and reinstalling it. |
| 13:02 |
JBoyer |
Dyrcona I can test a single machine, but the trouble is I can't trigger it on demand. |
| 13:03 |
Dyrcona |
JBoyer: Well, I think that select() call is your problem. |
| 13:03 |
Dyrcona |
You would never want to call it that way. |
| 13:03 |
Dyrcona |
If you set the first arg to zero, and the next 3 to NULL, you definitely want something in the final argument. |
| 13:04 |
Dyrcona |
Hmmm...... |
| 13:04 |
Dyrcona |
tsbere: Was the default erlang package busted on 14.04? |
| 13:05 |
kmlussier |
jeff: Can I remove you from bug 1312824? |
| 13:05 |
pinesol_green |
Launchpad bug 1312824 in Evergreen "open-ils.circ.hold.change_title(.specific_holds) APIs cancel previously captured holds at other locations, confusing staff and patrons" [Medium,Confirmed] https://launchpad.net/bugs/1312824 - Assigned to Jeff Godin (jgodin) |
| 13:05 |
jeff |
probably! |
| 13:05 |
* jeff |
looks |
| 13:05 |
Dyrcona |
IIRC, it was but was then fixed. |
| 13:06 |
JBoyer |
Well... If that's the case and it was fixed after Jan 1st, that could be why my VMs built in the last few weeks are fine, and it may not be hardware specific. |
| 13:06 |
tsbere |
Dyrcona: I don't recall it being busted, but I don't recall what versions (if any) ship with SMP enabled... |
| 13:07 |
JBoyer |
tsbere: None I'm aware of, I turn that on. |
| 13:07 |
Dyrcona |
I thought there was some kerfuffle and the maintainer was booted.... |
| 13:07 |
jeff |
kmlussier: all set -- removed myself. |
| 13:07 |
kmlussier |
jeff: Thanks! |
| 13:08 |
Dyrcona |
JBoyer: I think this has to do with the upgrade. When you're doing vms it's a fresh installation, right? |
| 13:08 |
JBoyer |
Yes. A by-hand install of Ubuntu, followed by fresh automated installs of everything else. |
| 13:09 |
Dyrcona |
Well, I won't repeat what I said earlier about issues (real or imagined) with a 12.04 to 14.04 upgrade, but this has a familiar ring to it. |
| 13:10 |
JBoyer |
No more reliable than these things are being, I can just blow one away and rebuild it to see what happens later. If it never freaks out I can go through a larger swath of them later. |
| 13:13 |
tsbere |
Dyrcona: There was a short period of time with a bad compile, but nobody should be seeing it now |
| 13:14 |
Dyrcona |
tsbere: OK |
| 13:28 |
jeff |
stupid reporting tricks: mailing address labels that print each morning if there were any "limited juvenile" patrons created yesterday. |
| 13:28 |
jeff |
did you get a pdf? print it on avery XXXX stock and drop those letters in the mail! |
| 13:29 |
jeff |
(letters have no customized data in them, or we'd be printing them as well as part of the report or a sibling report) |
| 13:29 |
jeff |
i was just pleased that the labels aligned correctly once we got beyond the test period and got beyond one single patron. |
| 13:30 |
jeff |
(we now let patrons get a card without parent being present, but it's a limited card until their parent or guardian comes in to sign off on it) |
| 13:30 |
jeff |
limited to 3 items out at once. |
| 13:30 |
terran |
jeff++ |
| 13:31 |
jeff |
and since these are still less frequently than "daily", if there were no Limited Juvenile patrons created the day before, there's no pdf sent via email. |
| 14:13 |
|
rlefaive joined #evergreen |
| 15:35 |
|
ethomsen joined #evergreen |
| 15:51 |
|
ethomsen left #evergreen |
| 16:11 |
|
jlitrell joined #evergreen |
| 16:25 |
berick |
wondering what authority.record_entry.source is supposed to be used for. reserved for a not yet existing config.authority_source table? |
| 16:28 |
* jeff |
tests receipt printing with Hatch |
| 16:29 |
jeff |
huh. had to manually set margins in eg.print |
| 16:31 |
jeff |
no margin options in Windows print dialog spawned by hatch, and the paper type/size shown in the json sticks to Letter no matter how many times I select the "72mm x Receipt" option |
| 16:42 |
jeff |
in other apps, margins appear to be a distinct dialog. |
| 16:42 |
jeff |
hrm. |
| 16:45 |
Bmagic |
Has anyone changed from prefork to event on apache 2.4 ? |
| 16:56 |
berick |
jeff: my hope is to one day kill the java print dialog and just capture the values we want directly in a web app form. |
| 16:57 |
tsbere |
berick: And what happens when someone wants to set a print driver specific option? |
| 16:57 |
* tsbere |
runs into enough of those with receipt printers alone, nevermind larger printers with multiple output trays and such |
| 17:02 |
jeff |
Bmagic: I've not tried. I am uncertain if the various modules are thread safe. |
| 17:02 |
berick |
tsbere: well, support for storing those values would have to be added to the web client anyway in its current form. it only knows how to store what it's told to store. it's been a long time since I looked at this stuff, but my recollection was that it wasn't possible to just dump the entire java print config into an opaque json blob and store it. i could be wrong about that, though. |
| 17:02 |
Bmagic |
roger |
| 17:02 |
berick |
jeff: Bmagic: various modules are not threadsafe |
| 17:02 |
berick |
specifically, opensrf |
| 17:03 |
Bmagic |
I see |
| 17:04 |
Bmagic |
so, we are definatly hitting our apache Maxconnection limit. We want to raise it up over 256, which means we probably need to introduce "ServerLimit" in addition to the default directives in prefork |
| 17:06 |
berick |
Bmagic: is your KeepAliveTimeout set to 1? |
| 17:06 |
Bmagic |
berick 5 |
| 17:07 |
Bmagic |
should it be 1? |
| 17:07 |
berick |
Bmagic: yes, it needs to be 1 for this exact reason |
| 17:09 |
jeff |
"email apparently invalid" has been a report with zero rows of output for a while (thank you email regex!), but now "freeform home location stat cat" is also. |
| 17:10 |
jeff |
so now we'll see how many days we go before someone enters a freeform township. |
| 17:10 |
|
mmorgan left #evergreen |
| 17:10 |
jeff |
and we can work to correct and bring things to the point where we can make that stat cat no longer permit freeform entry. |
| 17:26 |
* berick |
positive vibes to LP, hoping it returns to life |
| 17:28 |
* gmcharlt |
goes straight for the lightning storm |
| 17:29 |
berick |
beware gmcharlt's monster |
| 17:30 |
gmcharlt |
berick++ |
| 18:57 |
|
eby joined #evergreen |
| 20:11 |
jeff |
berick: are you aware of any recent work on hatch that isn't in the collab/berick/hatch2 or user/berick/hatch-installer-exp1 branch? |
| 20:11 |
jeff |
(same question for anyone else, i suppose!) |
| 20:14 |
|
jeff_ joined #evergreen |
| 20:38 |
|
gsams_ joined #evergreen |
