| Time |
Nick |
Message |
| 01:38 |
|
jamesrf joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
Dyrcona joined #evergreen |
| 08:29 |
Dyrcona |
@blame Retiree |
| 08:29 |
pinesol |
Dyrcona: Retiree is NOT CONNECTED TO THE NETWORK!!! |
| 08:29 |
|
littlet joined #evergreen |
| 08:29 |
Dyrcona |
pinesol: That's a good choice. |
| 08:29 |
pinesol |
Dyrcona: Dyrcona probably has a script for that. |
| 08:29 |
Dyrcona |
I probably do. I have a script for nearly everything. |
| 08:29 |
Dyrcona |
:) |
| 08:30 |
Dyrcona |
For those who don't know, krvmga retired, so I'm jokingly blaming all of the upgrade issue on him. :) |
| 08:31 |
Dyrcona |
Today's issue is a customization that he did miss for 3.2. |
| 08:32 |
Dyrcona |
I'm gonna move all of these out of the cwopac_templates custom directory and just track changes in the main templates directory via git. We did that at MVLC, and it makes it so you don't lose customizations between upgrades. |
| 08:32 |
Dyrcona |
It's easy to miss something depending on your tools and process when you keep the customization in a separate directory. |
| 08:36 |
|
mmorgan joined #evergreen |
| 09:02 |
|
collum joined #evergreen |
| 09:09 |
rhamby |
I have on my callendar an EOB meeting today but I know on conference months they often wait to have it at the conference. I assume that's the case this month? |
| 09:21 |
|
mdriscoll joined #evergreen |
| 09:22 |
|
sandbergja joined #evergreen |
| 09:22 |
|
aabbee joined #evergreen |
| 09:30 |
|
yboston joined #evergreen |
| 09:34 |
miker |
rhamby: it is the case. next meeting at the conf |
| 09:36 |
|
yboston joined #evergreen |
| 09:36 |
rhamby |
miker++ |
| 09:37 |
* rhamby |
does not send out an outreach update then ... |
| 09:39 |
Dyrcona |
"Curiouser and curiouser," said Alice. |
| 09:40 |
rhamby |
I just email out an outreach update ahead of the meetings rather than copy and pasting a bunch into the meeting. Seems simpler to me. |
| 09:42 |
* Dyrcona |
search Lp for a bug... No, looking through git logs might be easer.... |
| 09:42 |
Dyrcona |
Weird thing going on, but doesn't happen on a 3.2.5 system, only on 3.2.4, so I assume it's a patch we missed. |
| 09:43 |
|
Christineb joined #evergreen |
| 09:43 |
|
yboston_ joined #evergreen |
| 09:46 |
Dyrcona |
And, no. There doesn't appear to be a patch in 3.2.5.... |
| 09:47 |
mmorgan |
Dyrcona: What weirdness are you seeing? |
| 09:47 |
Dyrcona |
I'll show you. |
| 09:49 |
Dyrcona |
The content notes from 50X and 51X fields as well as subjects get doubled on this record: https://catalog.cwmars.org/eg/opac/record/4274449?locg=1;detail_record_view=0;sort=poprel;query=on%20the%20basis%20of%20sex;badges=1%2C1%2C1%2C1%2C1%2C1%2C1%2C1%2C1%2C1%2C1 |
| 09:49 |
Dyrcona |
But, only if you include the query in the URL: https://catalog.cwmars.org/eg/opac/record/4274449?locg=1;detail_record_view=0 |
| 09:50 |
Dyrcona |
It happens in Firefox and Chrome. It happens on our 3.2.4 production system as well as a test VM running the same code. It doesn't happen on our training server where the code is close, but based on 3.2.5. |
| 09:51 |
Dyrcona |
It happens on other records, too, but I haven't checked every single record, of course. |
| 09:54 |
mmorgan |
Dyrcona: Have a look at bug 1806724 |
| 09:54 |
pinesol |
Launchpad bug 1806724 in Evergreen "Display field strangeness on some 3.1+ systems" [Medium,Confirmed] https://launchpad.net/bugs/1806724 |
| 09:56 |
Dyrcona |
mmorgan: Thanks. I thought there was something related. However, we should be seeing this on training if that's the case, unless we applied your fix there and forgot about it. I'll check. |
| 10:00 |
Dyrcona |
Nope. Didn't make the change on training. Maybe our dictionary is missing there? |
| 10:00 |
* Dyrcona |
tries the fix on the test vm. |
| 10:01 |
Bmagic |
Dyrcona: General question: what specs do your Evergreen bricks use for EG > 2.12 |
| 10:01 |
Bmagic |
in terms of CPU/Memory |
| 10:05 |
Dyrcona |
mmorgan: I just replaced the view and nothing chagned. Do I need to do anything else? |
| 10:05 |
Dyrcona |
Oh, never mind. I checked the wrong URL. :) |
| 10:06 |
Bmagic |
I've been finding that 4CPU/16GB isn't stable for a machine with Evergreen > 2.12. It will make it through a day but generally will have a death spiral before the next day. I believe it's choking on CPU cycles because when I look, the CPU's are PEGed until service restart |
| 10:06 |
Dyrcona |
mmorgan++ Works for me! |
| 10:06 |
mmorgan |
Yay! |
| 10:06 |
Dyrcona |
Bmagic: I'll get to you in a moment. |
| 10:06 |
mmorgan |
mdriscoll++ |
| 10:06 |
Bmagic |
:) - no hurry |
| 10:18 |
Dyrcona |
Bmagic: Heads and drones are 16GB/8 CPUs. |
| 10:18 |
Dyrcona |
We have 1 head and 2 drones per brick with 5 bricks for a total of 5 brick heads and 10 brick drones. |
| 10:19 |
Dyrcona |
Each brick also runs 1 other server: bricks 1-4 run a SIP server, brick runs our z39.50/utility server, though we have two other utility servers that run most things. |
| 10:20 |
Dyrcona |
The utility servers for action triggers and other cron jobs are the ones that we've had the most trouble with. |
| 10:21 |
Dyrcona |
SIP servers are 8GB/8 CPUs |
| 10:22 |
Dyrcona |
Z39.50 is 16GB/8 CPUs |
| 10:24 |
Dyrcona |
Our extra util server, aka cron, is 16GB/8 CPUs. It only runs the fine generator, hold thawer, and reshelving complete: the jobs that mainly use open-ils.storage becasue we were having issues with storage and RAM on the main utility server. |
| 10:24 |
Bmagic |
it's the CPU |
| 10:24 |
Bmagic |
the conclusion I am coming to is: 4 isn't enough |
| 10:25 |
Dyrcona |
Might not be. |
| 10:26 |
Dyrcona |
Our main utility server is dedicated hardware and is also NFS for the bricks. It has 32GB and 16 cores. It runs pretty much all of our cron jobs. |
| 10:26 |
Bmagic |
thanks for the info! |
| 10:26 |
Dyrcona |
I find 4GB/4 cores (even 2) is sufficient for testing/development. |
| 10:27 |
Bmagic |
right, it wasn't until it went live that it started breaking |
| 10:28 |
Bmagic |
For the most part, the machine is quiet. But there are some seroius spikes and if there isn't enough CPU to handle it, the whole thing will go into a death spiral |
| 10:29 |
|
yboston joined #evergreen |
| 10:31 |
|
sandbergja joined #evergreen |
| 10:31 |
Dyrcona |
Yeah. More CPU is usually better. |
| 10:37 |
jeff |
in a virtualized environment, depending on your underlying hypervisor/etc, adding CPUs can hurt performance. |
| 10:43 |
bshum |
Happy Disco Dingo Day :) |
| 10:44 |
Dyrcona |
:) |
| 10:45 |
Dyrcona |
https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes |
| 10:45 |
Dyrcona |
Not recommended for production Evergreen use, but I may upgrade my laptop soonish. |
| 10:56 |
|
bwicksall joined #evergreen |
| 10:59 |
berick |
might I also recommend Frisky Dingo (if you like dumb cartoons) |
| 11:00 |
dbwells |
doesn't everyone? |
| 11:05 |
berick |
true |
| 11:05 |
berick |
i retract my caveat! |
| 11:11 |
Dyrcona |
:) |
| 11:44 |
|
sandbergja joined #evergreen |
| 11:53 |
|
khaun joined #evergreen |
| 11:54 |
|
nfBurton joined #evergreen |
| 12:06 |
|
_sandbergja joined #evergreen |
| 12:19 |
berick |
as a heads up, not having the hatch extension changes from bug 1793005 in the chrome/ff store is making hatch/angular development pretty cumbersome (because you have to install a local version of the app in chrome dev mode). |
| 12:19 |
pinesol |
Launchpad bug 1793005 in Evergreen 3.3 "Angular app needs hatch print support / Print Workstation Settings" [Undecided,New] https://launchpad.net/bugs/1793005 |
| 12:19 |
berick |
getting that posted to the stores sooner than later would be super cool |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:23 |
|
khaun joined #evergreen |
| 13:15 |
abowling |
attempting a reingest of metabib records. getting "ERROR: Cannot decode string with wide characters at /usr/lib/x86_64-linux-gnu/perl/5.22/Encode.pm." the records in question, i believe, are already decoded. anyone know a shortcut. i know the long way home. |
| 13:22 |
gmcharlt |
berick: what do you need to expedite gettng the stores updated? |
| 13:25 |
jeffdavis |
abowling: How are you doing the reingest? pingest.pl or ...? |
| 13:26 |
abowling |
jeffdavis: version-upgrade scripts |
| 13:26 |
jeffdavis |
ah |
| 13:26 |
abowling |
or, actually, the recommended path from the upgrade scripts. not technically in the bunch |
| 13:27 |
abowling |
select metabib.reingest_metabib_field_entries(id) FROM biblio.record_entry... |
| 13:28 |
jeffdavis |
If the error is happening on a particular trigger like maintain_901 or maintain_control_numbers, you could try disabling the trigger temporarily if it's safe to do so in your environment |
| 13:30 |
miker |
abowling: lots of variables ... perl version, pg version, db encoding, EG version (obv), search path (there may be old versions installed for some functions), content of records... |
| 13:31 |
abowling |
jeffdavis: miker: yep. i think i'm just going to have to find the secret sauce by trial/error |
| 13:37 |
jeffdavis |
abowling: (1) is the error restricted to a small number of records (and can you skip those records for now)? (2) what is the output of SHOW search_path; |
| 13:39 |
abowling |
jeffdavis: search_path |
| 13:39 |
abowling |
----------------- |
| 13:39 |
abowling |
"$user", public |
| 13:39 |
abowling |
i can skip them, but i'm at a migration point, so i'm operating from a standpoint that i'll probably just knock them out now |
| 13:39 |
abowling |
jeffdavis++ |
| 13:39 |
jeffdavis |
SET search_path TO evergreen, "$user", public; |
| 13:41 |
jeffdavis |
and in fact you probably should set it like that at the database level, something like 'ALTER DATABASE SET search_path = evergreen, public, pg_catalog;' |
| 13:42 |
jeffdavis |
check the postgres docs for the exact syntax for that command - the point is that "evergreen" needs to be listed first in your search_path |
| 13:42 |
jeffdavis |
since it's not, you are probably running into old but still-installed versions of db functions/triggers as a result |
| 13:43 |
abowling |
jeffdavis: that's almost certainly what i'm running into |
| 13:50 |
* Dyrcona |
suspects non-UTF8 in MARC records, but the search path, etc., are good places to start since they're quicker to resolve if that is the case. |
| 13:51 |
berick |
gmcharlt: at minimum, a sign off on the Hatch.git changes would suffice. I can upload the changes to the chrome store. |
| 13:51 |
berick |
and a FF stored upload volunteer as well |
| 14:11 |
jeff |
When using the hatch installer, the Chrome extension is installed. Does that extension come from the installer or from the chrome store? |
| 14:11 |
* jeff |
looks |
| 14:15 |
jeff |
Looks like it comes from the chrome web store. |
| 14:17 |
jeff |
So when a new version is pushed, it'll be 100% backward compatible with the existing deployed hatch native messaging host, and if and when there are changes required to the native messaging host, installing the new version will unlock those new features but the extension + native messaging host won't break in the meantime? |
| 14:19 |
berick |
jeff: that has been my standard op procedure, yes |
| 14:20 |
berick |
if the extension was going to break something, it would be a big announcement -- given how little the extension does (pass messages) at least something that big would be rare, hopefully never |
| 14:20 |
berick |
the latest change, fwiw, just adds to the config allowing access to /eg2/ |
| 14:23 |
berick |
well, /eg2/*/staff/* |
| 14:50 |
|
khaun joined #evergreen |
| 15:18 |
dbwells |
grabbing 1160 |
| 15:18 |
|
collum joined #evergreen |
| 15:21 |
|
sandbergja_ joined #evergreen |
| 15:27 |
jeff |
hrm. broke my 3.1 web client on my laptop again. |
| 15:32 |
Dyrcona |
jeff: Good. That shows you're trying. :) |
| 15:33 |
|
yboston joined #evergreen |
| 15:40 |
pinesol |
[evergreen|Bill Erickson] LP1818288 Ang staff catalog record detail holds tab/actions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ce5f238> |
| 15:40 |
pinesol |
[evergreen|Bill Erickson] LP1818288 Release notes - record holds tab - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=92cc36d> |
| 15:40 |
pinesol |
[evergreen|Bill Erickson] LP1818288 Grid checkboxes emit events - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb74421> |
| 15:40 |
pinesol |
[evergreen|Bill Erickson] LP1818288 WS Option to pre-fetch record holds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b7577f2> |
| 15:40 |
pinesol |
[evergreen|Dan Wells] Stamping upgrade script for holds prefetch setting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8c0482c> |
| 15:46 |
pinesol |
[evergreen|Dan Wells] Trivial change to file header comment - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7f08fdb> |
| 15:48 |
jeff |
no amount of storage clearing fixed it... after closing a few dozen tabs it started working again... |
| 15:48 |
Dyrcona |
Yeahp. |
| 15:49 |
Dyrcona |
Sounds 'bout right to me. |
| 15:51 |
jeff |
service worker appeared to be throwing errors, including Uncaught (in promise) DOMException |
| 15:54 |
Dyrcona |
I wasn't doing much. I just had 20 tabs open! |
| 15:54 |
Dyrcona |
And each tab is using 800+MB of RAM, unbeknownst to you. |
| 16:08 |
jeff |
3:11 # chrome 3 windows, 11 tabs |
| 16:08 |
jeff |
21:26:26 # iterm2 21 windows, 26 tabs, 26 sessions |
| 16:08 |
jeff |
that chrome number was much much higher a little bit ago :-) |
| 16:12 |
|
Christineb joined #evergreen |
| 16:14 |
jeffdavis |
jeff: we had a report of that same issue this week |
| 16:16 |
jeffdavis |
or at least that same error - one library reported "white screen of death" on a single workstation, with the console showing "Uncaught (in promise) DOMException" errors on the workstation registration page |
| 16:16 |
jeffdavis |
I have my fingers crossed that clearing up disk space might help |
| 16:17 |
jeff |
likely. |
| 16:20 |
Dyrcona |
I love it when an "idle" tab suddenly starts using 100% or so of CPU and the fan in my laptop starts spinning. |
| 16:20 |
Dyrcona |
YouTube in Firefox, I'm looking at you! |
| 16:20 |
Dyrcona |
Had it happen in Chromium recently, too. Killing the tab process usually fixes it. |
| 16:20 |
Dyrcona |
Well, always fixes it. |
| 16:21 |
Dyrcona |
Not sure it was YouTube in Chromium, though. |
| 16:40 |
|
yboston joined #evergreen |
| 16:56 |
|
mdriscoll left #evergreen |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 18:15 |
|
sandbergja joined #evergreen |
| 22:18 |
|
dbwells joined #evergreen |
| 23:57 |
|
sandbergja joined #evergreen |
