| Time |
Nick |
Message |
| 04:15 |
|
yar joined #evergreen |
| 05:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:29 |
|
jamesrf joined #evergreen |
| 06:51 |
|
jamesrf joined #evergreen |
| 06:59 |
|
agoben joined #evergreen |
| 07:08 |
|
JBoyer joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:14 |
|
bos20k joined #evergreen |
| 07:35 |
|
JBoyer joined #evergreen |
| 08:12 |
|
collum joined #evergreen |
| 08:48 |
|
aabbee joined #evergreen |
| 08:52 |
|
mmorgan joined #evergreen |
| 08:57 |
|
mmorgan1 joined #evergreen |
| 09:02 |
|
Stareagle joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:13 |
|
yboston joined #evergreen |
| 09:16 |
Dyrcona |
So, storage listener died last night while the fine generator was running. The drones are still there. That's all I know right now, but this is a familiar scenario that we've discussed before. |
| 09:20 |
Dyrcona |
The fine generator is also stuck in some kind of limbo. |
| 09:29 |
Dyrcona |
Zero indication of a problem in any of the logs. No OOM killer messages, no errors in syslogs, just a last message of cstore sending 400 bytes to a storage drone at 1:24:11 am. |
| 09:34 |
Dyrcona |
srfsh log has something potentially interesting.. |
| 09:37 |
|
sandbergja joined #evergreen |
| 09:39 |
Dyrcona |
I take that back. The srfsh log looks normal. |
| 09:40 |
Dyrcona |
The "destroying self and deleting requests" line is routine. |
| 09:42 |
Dyrcona |
BUT! It is interesting that this seemed to happen just after the reshelving complete script ran, so maybe the fine generator and the reshelver don't always get along? |
| 09:43 |
Dyrcona |
@monologue |
| 09:43 |
pinesol |
Dyrcona: Your current monologue is at least 8 lines long. |
| 09:43 |
* Dyrcona |
feels like Bob Dylan. :P |
| 09:47 |
Bmagic |
lol |
| 09:49 |
aabbee |
hey, evergreen-ils.org showed up on hackernews https://news.ycombinator.com/item?id=19848782 |
| 09:49 |
Bmagic |
I'm catching up with your monologue - recently I've had cstore run out of children (no children available) which bascially broke everything on the utility server. I believe it stemmed from a malformed tt2 template in a ProcessTemplate trigger which someow bled into everything |
| 09:51 |
Dyrcona |
Bmagic: I know I'm not running out of children. This looks like running out of memory, but I'm considering adjusting the fine generator and reshelving complete schedules in crontab. |
| 09:51 |
Bmagic |
couldn't hurt |
| 09:51 |
Bmagic |
aabbee++ # sweet |
| 09:52 |
Dyrcona |
aabbee: And the discussion is rather unflattering. |
| 10:00 |
berick |
Dyrcona: the fine generator having to wait for the reshelving script to complete sounds very familiar. i thought there was an old bug, but can't find it. if it happens, i would expect you to see errors related to waiting for locks in the PG logs. |
| 10:03 |
* berick |
reads irc meeting notes |
| 10:13 |
Dyrcona |
berick: Thanks for mentioning that. |
| 10:13 |
Dyrcona |
It looks like our overdue scripts also run at the same time. |
| 10:14 |
Dyrcona |
Same time as the reshelving complete job, that is. They now run on different util servers, but still the same database. |
| 10:15 |
Dyrcona |
Could be some deadlocks going on there, too. |
| 10:15 |
Dyrcona |
I'll check the pg logs. |
| 10:19 |
Dyrcona |
Bleh... whole MARC fields showing up in the logs. Probably a long-running query or some other failure. |
| 10:21 |
Dyrcona |
And, no. Nothing about locks in the logs for the relevant time period. We may not be logging locks in Postgres. |
| 10:34 |
JBoyer |
Calling 1163, let's see how this goes. |
| 10:34 |
* berick |
holds JBoyer's beer |
| 10:35 |
JBoyer |
berick++ |
| 10:35 |
Dyrcona |
:) |
| 10:53 |
* JBoyer |
probably hasn't broken anything, feels that's a win. |
| 10:55 |
Dyrcona |
You want someone to review what you did before you push it? |
| 10:55 |
pinesol |
[evergreen|Jason Boyer] LP1820339: Vandelay Imports on Pg 10 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4ce0587> |
| 10:55 |
pinesol |
[evergreen|Jason Stephenson] LP1820339: Vandelay Imports on Pg 10 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=50c05dd> |
| 10:55 |
pinesol |
[evergreen|Jason Boyer] Stamping upgrade script for Vandelay on PG10 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=296bf51> |
| 10:55 |
Dyrcona |
Well, never mind. :) |
| 10:56 |
JBoyer |
I thought about that, then ended up testing it on production, as it were. :) |
| 10:57 |
Dyrcona |
Well, you put your name in twice in a comment, but other than that it looks good in the diff email. :) |
| 10:57 |
bshum |
JBoyer: Not sure if it'll help, but a handy trick I like when doing my upgrade script stamping is to use "git mv" to move the original xxxx.sql file to the ####.sql |
| 10:57 |
bshum |
Also JBoyer++ Dyrcona++ |
| 10:58 |
JBoyer |
Dyrcona, I thought the convention was author/signoff(s)/committer, so I was kind of unsure about that bit. It does look funny. |
| 10:58 |
|
mmorgan joined #evergreen |
| 10:59 |
Dyrcona |
Doesn't matter, really. I'm just looking to nitpick. ;) |
| 10:59 |
JBoyer |
bshum, I do like that and git rm a lot. (especially since git commit -A has gotten pickier about some things over the years) |
| 10:59 |
bshum |
Maybe it's just gitweb being funky in how it displays changes. Awesome. |
| 10:59 |
Dyrcona |
The mail looks like the file was properly renamed/mv'd. |
| 11:00 |
JBoyer |
yeah, I think that |
| 11:01 |
JBoyer |
s just gitweb doing something odd, I think others look the same, not sure what it's doing there, |
| 11:02 |
Dyrcona |
Git sometimes gets weird with diffs. Different git commands will sometimes show different diffs, or will show things differently from the ordinary diff command. |
| 11:11 |
* Dyrcona |
turns on log_lock_waits in the evergreen database. |
| 11:47 |
|
sandbergja joined #evergreen |
| 11:54 |
mmorgan |
Hatch question du jour: can it be installed on a Mac? |
| 11:55 |
|
jihpringle joined #evergreen |
| 12:04 |
|
sandbergja_ joined #evergreen |
| 12:11 |
|
sandbergja_ joined #evergreen |
| 12:13 |
JBoyer |
mmorgan, in theory! But I'm out of practice. |
| 12:14 |
mmorgan |
:) |
| 12:14 |
JBoyer |
In short, I think so. I think berick has gotten it to work before but I don't think there are explicit instructions. |
| 12:15 |
mmorgan |
Ok, so no neat tidy package like for Windows. |
| 12:15 |
JBoyer |
I'm not certain if the OpenJDK changes in Hatch master work on a Mac or if you have to use a specific Java VM, and then the question of browser config is beyond me. I assume it |
| 12:16 |
jeff |
berick: the copy alert migration strategy we discussed may need adjusting, i'm looking into a report of copies with asset.copy.alert_message set failing checkin in the web client. |
| 12:16 |
JBoyer |
s similar to the Linux config, and that Safari will have no part of it. |
| 12:16 |
JBoyer |
Certainly no simple installer, no. :( |
| 12:17 |
mmorgan |
JBoyer: Thanks, that answers my question for the time being. |
| 12:18 |
mmorgan |
JBoyer++ |
| 12:19 |
* mmorgan |
is interested in jeff's experience with copy alerts. |
| 12:23 |
|
khuckins joined #evergreen |
| 12:27 |
|
sandbergja_ joined #evergreen |
| 12:43 |
jeff |
mmorgan, berick: looks like it may be unrelated to copy alerts. for one thing, the report changed to "there was a long delay", and it might also be related to hold capture verify or copy location alerts. so many dialogs to choose from! |
| 12:44 |
mmorgan |
Indeed! |
| 12:50 |
|
yboston joined #evergreen |
| 12:55 |
berick |
mmorgan: the process for running Hatch on Mac will be very similar to Linux. For the JDK11 / openjfs stuff, there are Mac builds. However, the branch doesn't hvae a dependency fetcher entry for Mac, so for you they have to be fetched by hand and unpacked into the right place |
| 12:55 |
berick |
*openjfx |
| 12:57 |
JBoyer |
It may be very easy to make the Linux fetcher work though, since the bash installed with MacOS will happily run the same script that any other bash will. :) Something else to explore (like making an all-windows build script for PS or the new Windows Terminal...) |
| 12:58 |
|
Christineb joined #evergreen |
| 12:58 |
berick |
JBoyer: yes, definitely, the fetcher should work fine, just needs a few more lines |
| 13:06 |
JBoyer |
That also wasn't me saying "you should have no trouble with this!" ;) Almost makes me wish I had a MacBook so I could work on it before I get home. |
| 13:06 |
* berick |
*nod* |
| 13:06 |
berick |
i just so happen to have an imac.. might look at it today |
| 13:10 |
|
sandbergja_ joined #evergreen |
| 13:18 |
JBoyer |
berick++ |
| 13:42 |
Dyrcona |
miker: We talked about some possible optimizations for the fine generator at the conference. I have some ideas for a fine_generator_v2.pl that could eventually replace fine_generator.pl the way that hold_targeter_v2.pl replaced hold_targeter.pl. I'll write up a bug report later this week or next. |
| 13:48 |
miker |
Dyrcona++ |
| 14:03 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "For bshum: Pg versions on dumbo" (20 lines) at http://paste.evergreen-ils.org/10872 |
| 14:04 |
Dyrcona |
I didn't exactly want 11 installed, yet, but oh well..... |
| 14:06 |
bshum |
Dyrcona: Hmm, busy server :) |
| 14:07 |
Dyrcona |
And, looks like the ports were bumped logically: 9.5 is 5432, 11 is 5433, and 10 is 5434, following the order of installation, I assume. |
| 14:07 |
berick |
mmorgan: there should be enough tools and documentation in bug #1817932 for running Hatch on Mac. Requires using the git working branch noted in the bug. |
| 14:08 |
pinesol |
Launchpad bug 1817932 in Evergreen "Update Hatch Java / Javafx versions" [Undecided,Confirmed] https://launchpad.net/bugs/1817932 |
| 14:08 |
mmorgan |
berick++ |
| 14:09 |
mmorgan |
Thanks for the guidance! |
| 14:11 |
* Dyrcona |
considers install Pg 9.6, but maybe that's going too far. :) |
| 14:45 |
|
khuckins joined #evergreen |
| 15:00 |
* Dyrcona |
attempts a pg restore of Sunday's dump into Pg 10, and expects it to fail. |
| 15:00 |
|
yboston joined #evergreen |
| 15:03 |
Dyrcona |
Yeahp. Didn't get far at all before the fireworks started. |
| 15:05 |
* Dyrcona |
starts over and lets it go with |& tee log |
| 15:13 |
|
yar joined #evergreen |
| 15:58 |
Dyrcona |
A belated JBoyer++ and bshum++ |
| 15:59 |
yboston |
Hello folks, can someone share with me how does the Evergreen community allow doc committers to ONLY be able make commits that live inside the “/docs” path? I want to share what this community does with some folks from the Islandora community. Thanks |
| 16:01 |
Dyrcona |
We use gitolite configuration to do it. |
| 16:03 |
Dyrcona |
RW VREF/NAME/docs/ = @docwriters |
| 16:03 |
Dyrcona |
That's the effective line in the Evergreen repo config. |
| 16:04 |
Dyrcona |
https://gitolite.com/gitolite/cookbook#vrefs |
| 16:04 |
Dyrcona |
If they're not using gitolite, they need to explore other options. |
| 16:05 |
|
jamesrf joined #evergreen |
| 16:10 |
Dyrcona |
There's more to it, yboston. We also have to block them from everything else after. |
| 16:11 |
|
yboston_ joined #evergreen |
| 16:12 |
yboston_ |
Dyrcona: thanks. They are just suing Github right now, so there might not have many options |
| 16:12 |
yboston_ |
Dyrcona: I wanted to at least give them the EG approach for now |
| 16:12 |
Dyrcona |
I don't know how you'd do that on Github. It can be done with Gitlab, IIRC. |
| 16:14 |
|
dkyle joined #evergreen |
| 16:14 |
|
_bott_ joined #evergreen |
| 16:15 |
|
book` joined #evergreen |
| 16:16 |
|
Bmagic joined #evergreen |
| 16:16 |
Dyrcona |
yboston: It looks like you can protect branches on Github, but not directories. |
| 16:31 |
|
yar joined #evergreen |
| 16:53 |
|
abowling joined #evergreen |
| 17:01 |
|
stephengwills joined #evergreen |
| 17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
stephengwills joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 18:02 |
|
stephengwills joined #evergreen |
| 18:12 |
|
khuckins joined #evergreen |
| 20:42 |
|
sandbergja joined #evergreen |
