| Time |
Nick |
Message |
| 00:19 |
|
jvwoolf joined #evergreen |
| 01:19 |
|
haishulibrary joined #evergreen |
| 01:20 |
haishulibrary |
Hello! I am looking at installing a library system for my Kindergarten (we have an awefully big library for what we are) and I had some questions about the software |
| 06:28 |
csharp |
haishulibrary: this channel is mostly active between 9:00 a.m. and 5:00 p.m. Eastern Time, so please time your questions then if possible - also consider the mailing lists: https://evergreen-ils.org/communicate/mailing-lists/ |
| 06:29 |
csharp |
but I'm around now and may be able to help |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
rfrasur joined #evergreen |
| 07:39 |
|
Dyrcona joined #evergreen |
| 07:46 |
|
tlittle joined #evergreen |
| 07:53 |
|
tlittle15 joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 08:23 |
jeff |
There's no need to time your questions... just to time your expectations of a response. :-) |
| 08:24 |
|
collum_ joined #evergreen |
| 08:27 |
|
stephengwills joined #evergreen |
| 08:33 |
Dyrcona |
busetd-websites-- |
| 08:33 |
Dyrcona |
busted, even.... |
| 08:33 |
Dyrcona |
The typo seems appropriate.... |
| 08:35 |
Dyrcona |
haishulibrary: Just ask your questions. |
| 08:42 |
|
mmorgan joined #evergreen |
| 09:09 |
Dyrcona |
So, "Returning NULL from ...." My understanding is that these are requests that timed out, usually. And, by the time that I become aware of them and go to investigate, the data is cached and gets returned instantly. |
| 09:10 |
Dyrcona |
Has anyone ever pulled a list of these requests from their logs and attempted to investigate why they time out? |
| 09:12 |
Dyrcona |
Some of the ones that I see this morning seem like they shouldn't have timed out or returned null, open-ils.circ.retrieve, for instance. |
| 09:20 |
Dyrcona |
All of them on the same brick this time. |
| 09:24 |
|
yboston joined #evergreen |
| 09:26 |
mmorgan |
Dyrcona: I'm not finding messages like that in our logs |
| 09:28 |
Dyrcona |
Fair enough. I see them in the gateway logs quite often. "Returning NULL from app_request_recv after timeout:" |
| 09:29 |
Dyrcona |
With the other log stuff before and the actual request after. |
| 09:30 |
Dyrcona |
When I run the requests via srfsh after the fact, they usually respond right away, or I get NO_SESSION if the authtoken in the log is no longer valid. |
| 09:39 |
Dyrcona |
I'm not even close to running out of connections on PostgreSQL, and I don't see any of the queries in the PostgreSQL logs as long running queries or with errors. |
| 09:41 |
|
jvwoolf joined #evergreen |
| 09:42 |
Dyrcona |
Also, no "NOT CONNECTED TO THE NETWORK" errors for the time period in question, though it does appear that drones are dying or just not responding. |
| 09:44 |
Dyrcona |
Oddly, enough, I've got not connected errors for hours 5,6,7, and 9 this morning, and returning null errors only for hours 8 and 9 this morning, with only 1 after 9:00 am. |
| 09:45 |
Dyrcona |
All of the ones at 8:00 am are on the same brick, and the one at 9:20 am is on a different brick, and it's a reporter folder retrieve, which I've seen timeout before. |
| 09:46 |
Dyrcona |
When this happens at a high enough threshold for nagios to notice, it's usually two or three bricks. |
| 09:47 |
mmorgan |
Dyrcona: We do get a smattering of "NOT CONNECTED TO THE NETWORK" errors throughout the logs |
| 09:48 |
Dyrcona |
Yes, and I don't think they're related, though I suspect drones are dying in both cases, but in the "returning null" case, opensrf isn't noticing. |
| 09:49 |
Dyrcona |
Or, maybe it is noticing, the drone is just dying too soon, and that sounds familiar, like there's possibly a bug on that. |
| 09:51 |
Dyrcona |
I'll explore the drones being shut down prematurely angle and see where that leads. |
| 09:52 |
Dyrcona |
mmorgan++ |
| 10:07 |
|
nfBurton joined #evergreen |
| 10:10 |
|
jvwoolf left #evergreen |
| 10:14 |
|
aabbee joined #evergreen |
| 10:15 |
|
jvwoolf joined #evergreen |
| 10:50 |
|
yboston joined #evergreen |
| 11:00 |
|
jvwoolf joined #evergreen |
| 11:02 |
pinesol |
News from qatests: Failed Installing AngularJS web client - Expected 6 errors but encountered 7. <http://testing.evergreen-ils.org/~live/test.28.html#2019-10-31T11:00:53,501226777-0400 -0> |
| 11:02 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-10-31T11:00:53,543262504-0400 -2> |
| 11:12 |
|
sandbergja joined #evergreen |
| 11:42 |
|
jihpringle joined #evergreen |
| 11:49 |
|
awitter joined #evergreen |
| 12:09 |
|
Christineb joined #evergreen |
| 12:30 |
|
yboston joined #evergreen |
| 12:31 |
Dyrcona |
Stompro: There has to be a minimal set of universally required fields in patron registration/edit: those fields that do not allow null and do not have default values in the actor.usr table. |
| 12:32 |
Stompro |
Dyrcona, thanks. |
| 12:34 |
Dyrcona |
net_access_level is not one of those fields, so it could be a candidate for a hide/show option. |
| 12:44 |
csharp |
well, 5 hours and counting running 1188 in the 3.3.3-3.4.0 upgrade script |
| 12:45 |
Dyrcona |
:) |
| 12:45 |
csharp |
UPDATE action.circulation SET auto_renewal = FALSE WHERE auto_renewal IS NULL; - still on that - next is aged circs which is way larger a table |
| 12:45 |
csharp |
wondering if we can disable triggers somewhere before this is run? |
| 12:45 |
Dyrcona |
Going from 3.2.4 to 3.2.8 with those updates takes about 22 hours on my test db server. |
| 12:46 |
Dyrcona |
csharp: That's a good idea. I don't think anything depends on the values of those desk_renewal or auto_renewal fields trigger-wise. |
| 12:46 |
csharp |
yeah - just thinking the same thing |
| 12:47 |
csharp |
in other news it just got dark as night outside - methinks something wicked this way comes |
| 12:47 |
* Dyrcona |
looks. |
| 12:47 |
Dyrcona |
That does sound ominous. It has been raining here all day. |
| 12:48 |
* JBoyer |
would like to remind csharp that unless staff are beating down the door to run reports on that field it could be done out of band, in smaller chunks. |
| 12:48 |
JBoyer |
But yes, it's about as fast (and as fun!) as a vacuum full action.circulation. |
| 12:50 |
Dyrcona |
JBoyer: I would like to do the update as part of the db upgrade script, so as not to have to remember to do it later. |
| 12:51 |
mmorgan |
The update could also be done before... |
| 12:51 |
JBoyer |
mmorgan++ |
| 12:51 |
JBoyer |
even better. |
| 12:51 |
csharp |
JBoyer: I thought about that approach too - just doing it in advance of the upgrade |
| 12:53 |
JBoyer |
Dyrcona, I can see that, if it will complete fast enough. GIven that there's precious little visibility to staff though (until after the update is finished anyway, Dyrcona++ for the IDL updates) I wouldn't let it keep me up very late, or services down very long. |
| 12:54 |
Dyrcona |
We usually plan on things being down all night when we upgrade, but I'm going to look into disabling triggers and try it on a test db. I've got plenty of those to mess with. :) |
| 12:57 |
csharp |
yeah, trying the disable triggers approach too right now |
| 12:58 |
csharp |
I don't mind being down all night either, but without those updates, the 3.3-3.4 upgrade took me like 5 minutes running the scripts manually |
| 12:58 |
Dyrcona |
I've identified 5 triggers. |
| 12:58 |
Dyrcona |
Yeah, the rest of it runs pretty fast. |
| 12:59 |
Dyrcona |
We update something like 75 million rows on action.aged_circulation. |
| 13:00 |
Dyrcona |
Thirteen or 14 million on action.circulation. |
| 13:09 |
Dyrcona |
I forget, can the triggers be dropped inside the transaction where the update happens? |
| 13:11 |
|
khuckins joined #evergreen |
| 13:12 |
|
dbriem joined #evergreen |
| 13:14 |
jeff |
Dyrcona: I believe my usual is to do ALTER TABLE foo DISABLE TRIGGER USER within the transaction. |
| 13:15 |
Dyrcona |
jeff: Yeah that's better than dropping the trigger outright. |
| 13:15 |
* Dyrcona |
adjusts the script. |
| 13:15 |
|
sandbergja joined #evergreen |
| 13:18 |
jeff |
also doesn't require that you re-create or even know the name of the triggers. |
| 13:18 |
jeff |
DISABLE TRIGGER USER doesn't help if your system-level triggers are what are actually slowing you down. also doesn't help when you need to disable some-but-not-all triggers. |
| 13:19 |
jeff |
but even with those considerations, still useful. :-) |
| 13:19 |
Dyrcona |
Yeah. I think USER will work in this case. |
| 13:20 |
Dyrcona |
I was just going to disable the UPDATE triggers, but one line is easier to type than five. :) |
| 13:27 |
|
jihpringle joined #evergreen |
| 13:30 |
Dyrcona |
If this doesn't offer much improvement, I could disable ALL triggers, since nothing being updated relies on foreign keys....But, I don't recommend that to the viewer at home. :) |
| 13:32 |
JBoyer |
DROP CONSTRAINT *.*; -- PARTY ON WAYNE, PARTY ON GARTH. |
| 13:34 |
Dyrcona |
Looks like ALTER TABLE ... DISABLE TRIGGER ALL; will do that. |
| 13:35 |
Dyrcona |
"We're not worthy!" |
| 13:36 |
jeff |
the other thing to remember is that DISABLE TRIGGER {USER|ALL} followed by ENABLE TRIGGER {USER|ALL} will re-enable any triggers that were disabled before the DISABLE TRIGGER. |
| 13:36 |
jeff |
(which may be rare, but worth noting) |
| 13:37 |
Dyrcona |
So noted. |
| 13:37 |
Dyrcona |
:) |
| 13:38 |
Dyrcona |
So, it's up to the first update on action.circulation. Guess I'll know in a few hours if disabling the user triggers helps or not. |
| 13:44 |
Dyrcona |
This seems to have made a big improvement. It has already finished the first update. |
| 13:45 |
csharp |
oh - great |
| 13:45 |
csharp |
what syntax did you end up using? |
| 13:45 |
csharp |
disable trigger all? |
| 13:51 |
Dyrcona |
ALTER TABLE action.circulation DISABLE TRIGGER USER; |
| 14:12 |
* JBoyer |
has to look out the window a second time to confirm that there is, in fact, snow falling. |
| 14:13 |
berick |
JBoyer: holy cow. it's 78 here. |
| 14:13 |
csharp |
@weather 30084 |
| 14:13 |
pinesol |
csharp: Error: Failed to load Wunderground API. Check the logs for more information. |
| 14:13 |
csharp |
d'oh |
| 14:14 |
JBoyer |
only ~34 right now so it's not sticking or anything, but still a surprise. |
| 14:14 |
csharp |
it's dropped like 15 degrees in the last hour or so here |
| 14:14 |
csharp |
now 59 |
| 14:14 |
berick |
that'll be us tonight |
| 14:29 |
Dyrcona |
It's 70 here. |
| 14:31 |
jeff |
rain and snow here, with a gale warning until 11 PM. |
| 14:31 |
dbs |
Expecting 15 cm of snow here, it's been snowing all day |
| 14:31 |
Dyrcona |
And the rain let up. |
| 14:32 |
jeff |
>Expect occasional wintry mix to continue for the next several hours. |
| 14:32 |
* dbs |
starts digging around to find the right permissions for viewing triggered event logs |
| 14:32 |
jeff |
oh, gale warning + winter weather advisory + lakeshore flood advisory |
| 14:32 |
* Dyrcona |
thinks dbs had better start digging around for the snow shovel.... :) |
| 14:33 |
Dyrcona |
jeff: Get out of there.... ;) |
| 14:33 |
Dyrcona |
Run for the hills! :P |
| 14:33 |
jeff |
"waves of 4 to 8 feet along the Lake Michigan shoreline, with locally higher waves possible" |
| 14:33 |
dbs |
Get out the surfboard! |
| 14:34 |
Dyrcona |
:) |
| 14:34 |
Dyrcona |
The wind is picking up here. I think I'll check the actual forecast rather than current conditions. |
| 14:36 |
Dyrcona |
Hm... I think the weather channel has me set to centrigrade: 21 degrees right now. |
| 14:37 |
Dyrcona |
High wind advisory and rain all night. Nothing too serious. |
| 14:56 |
mmorgan |
Fireworks in Salem are cancelled due to high wind advisory :-( |
| 14:59 |
csharp |
dbs: if the problem is that the triggered event logs don't load for people see bug 1207533 (though the last comment points to some improvement maybe |
| 14:59 |
csharp |
) |
| 14:59 |
pinesol |
Launchpad bug 1207533 in Evergreen "Triggered event log times out for large-data sites" [Medium,Confirmed] https://launchpad.net/bugs/1207533 |
| 15:05 |
|
jvwoolf1 joined #evergreen |
| 15:09 |
|
khuckins joined #evergreen |
| 16:34 |
|
jvwoolf1 left #evergreen |
| 16:35 |
|
yboston joined #evergreen |
| 16:46 |
|
serflog joined #evergreen |
| 16:46 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration |
| 16:52 |
dbs |
csharp: thanks but the problem seems to be an inability to select anything in the OrgUnit selector |
| 16:53 |
* dbs |
heads out into the sleet and snow |
| 16:56 |
csharp |
dbs: ah - yeah that's usually dojo for "haha you don't have the perms, but I'm going to make you put in a helpdesk ticket to find that out from your admin" :-) |
| 17:01 |
|
mmorgan left #evergreen |
| 18:23 |
|
pastebot joined #evergreen |
| 19:15 |
|
cmalm joined #evergreen |
| 19:56 |
|
sandbergja joined #evergreen |
| 20:42 |
|
sandbergja joined #evergreen |
| 23:02 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live/test.29.html#2019-10-31T23:00:47,528691059-0400 -0> |
| 23:27 |
|
sandbergja joined #evergreen |
