| Time |
Nick |
Message |
| 08:03 |
|
BDorsey joined #evergreen |
| 08:36 |
|
Stompro joined #evergreen |
| 08:39 |
|
jmurray-isl joined #evergreen |
| 09:02 |
|
bgillap joined #evergreen |
| 09:05 |
|
dguarrac joined #evergreen |
| 09:19 |
|
Rogan joined #evergreen |
| 10:22 |
|
mantis joined #evergreen |
| 10:53 |
|
BrianK joined #evergreen |
| 11:01 |
|
Tomato joined #evergreen |
| 11:23 |
|
Christineb joined #evergreen |
| 11:28 |
|
Dyrcona joined #evergreen |
| 11:34 |
|
kworstell-isl joined #evergreen |
| 11:46 |
|
JBoyer joined #evergreen |
| 11:49 |
Bmagic |
on my utility server, I have repeating logs that say this: |
| 11:49 |
Bmagic |
open-ils.trigger [WARN:578048:Server.pm:200:] server: no children available, waiting... consider increasing max_children for this application higher than 20 in the OpenSRF configuration if this message occurs frequently |
| 11:50 |
Bmagic |
and when I run this command: /osrf_control -l --diagnostic |grep trigger I get this: * open-ils.trigger [578048] uptime=3-00:42:38 cputime=00:30:13 #drones=1/20 5% |
| 11:51 |
Bmagic |
ps aux|grep trigger|grep Drone likewise returns one result. So, it would seem that the Evergreen stack is wrong |
| 11:54 |
Bmagic |
My theory is that some previously running action_trigger_runner failed mid-stream. And the Evergreen stack didn't understand that, so it still thinks it's running? |
| 12:06 |
mantis |
question on the rel_3_9_4 branch |
| 12:06 |
mantis |
https://git.evergreen-ils.org/?p=Evergreen.git;a=tree;f=Open-ILS/web/js/dojo/openils/User/nls;hb=refs/heads/tags/rel_3_9_4 |
| 12:06 |
mantis |
are the sub directories that used to be here such as en-US gone somewhere else? |
| 12:07 |
mantis |
Dojo isn't working properly in our servers for certain pages like the Acq Marc Loader |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:15 |
Bmagic |
mantis: looks like 3.9.3 has the same folder: https://git.evergreen-ils.org/?p=Evergreen.git;a=tree;f=Open-ILS/web/js/dojo/openils/User/nls;h=bbdb17aaf27745fd6b1b6e3ec15f92e94b7a01aa;hb=refs/heads/tags/rel_3_9_3 |
| 12:15 |
mantis |
looking deeper |
| 12:15 |
mantis |
it appears that Evergreen isn't installing en-US in the dojo repo for us |
| 12:15 |
mantis |
and probably hasn't for a while |
| 12:15 |
jeff |
Bmagic: yeah, it sounds like the listener's idle_list (and perhaps active_list) may no longer be reflecting reality. are there any warnings or errors in the osrf_control output that your grep is hiding? looking at the children with ps and/or restarting the service are possible next steps, depending on if you're trying to recover quickly or identify the underlying issue. :-) |
| 12:16 |
Bmagic |
jeff: the grepped out osrf_control output is all normal |
| 12:17 |
Bmagic |
I did this just now: osrf_control -l --stop --service open-ils.trigger |
| 12:18 |
Bmagic |
after that finished (it took a long time) - I noticed that there was still a trigger Listener in the ps table. So I manually killed that process. Followed up with a removal of the pid file in /openils/var/run/opensrf. Then followed that up with a --start. Everything seems fine again |
| 12:18 |
|
jvwoolf joined #evergreen |
| 12:19 |
Bmagic |
This problem happens far too frequently for me to have to do this by hand each time. I want to fix this automatically. So, I think I'm going to write something that greps the logs for this children error, compare that to the real number of children, and if it's wrong, then basically automate the steps that I just described |
| 13:06 |
Dyrcona |
mantis: Install from Git. (I'm of the opinion that we should stop making release tarballs.) |
| 13:19 |
|
jihpringle joined #evergreen |
| 13:27 |
Dyrcona |
Bmagic: If you configured rsyslog on the server, you can set up a filter on syslog to trigger the restart whenever the message comes though. |
| 13:28 |
Dyrcona |
syslogng can do it, too. |
| 13:28 |
Bmagic |
neato |
| 13:29 |
Bmagic |
I was thinking the threshold would tolerate a few log messages but not more than X number in the last hour |
| 13:30 |
Dyrcona |
Well, your filter is a program, so it can track whatever you want. Now that I think about it, it will run as the syslog user, so it would probably have to sudo or something to restart services. I've used this feature before, but not for restarting OpenSRF services. |
| 13:33 |
|
kworstell_isl joined #evergreen |
| 13:43 |
Dyrcona |
We've got some AngularJS grids, namely the holds pull list, where some fields are turning up "null" if you mouse over them or try to print the full grid. This just started after we installed the open-ils.fielder patch, however it doesn't seem to be related because it happens on a test system without the fielder patch. Does this ring a bell for anyone? |
| 13:44 |
Dyrcona |
I've also been told by a reliable source that it isn't Lp 1785260. |
| 13:44 |
pinesol |
Launchpad bug 1785260 in Evergreen "Web Client: Holds Pull List - fields blank when using "Print Full Grid" or "Download Full CSV"" [Undecided,Confirmed] https://launchpad.net/bugs/1785260 |
| 14:13 |
Dyrcona |
This is frustrating. |
| 15:06 |
Dyrcona |
Node-- |
| 15:07 |
Dyrcona |
It definitely looks like this problem is caused by a change in a Node package/module, but which one. |
| 15:22 |
|
sleary joined #evergreen |
| 15:43 |
|
kworstell-isl joined #evergreen |
| 16:09 |
Dyrcona |
s/\^/~/ seems to resolve it. |
| 16:36 |
|
jvwoolf joined #evergreen |
| 16:52 |
|
kworstell_isl joined #evergreen |
| 16:58 |
Stompro |
Would anyone mind if the marc_export script sorted the output by bre.id when the bib ids are not being supplied? I just like there to be a consistent order. |
| 17:00 |
|
mantis left #evergreen |
| 17:27 |
Bmagic |
Stompro: I' |
| 17:27 |
Bmagic |
I'm surprised it's not already. I support your cause. Go for it! |
| 17:32 |
|
jvwoolf left #evergreen |
| 19:11 |
|
jihpringle joined #evergreen |
| 20:53 |
|
sandbergja joined #evergreen |
| 21:02 |
|
sandbergja joined #evergreen |
| 21:20 |
|
sandbergja joined #evergreen |
| 21:27 |
|
sandbergja joined #evergreen |
