| Time |
Nick |
Message |
| 03:41 |
|
serflog joined #evergreen |
| 03:41 |
|
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 |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
agoben joined #evergreen |
| 08:01 |
|
kmlussier joined #evergreen |
| 08:33 |
_bott_ |
Silly question. Where did the logic from PasswordReset.pm end up? |
| 08:34 |
|
collum joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:38 |
|
yboston joined #evergreen |
| 08:50 |
tsbere |
_bott_: I think open-ils.actor has a password reset call or two and EGCatLoader/Account.pm has the TPac side of things? |
| 08:52 |
|
bos20k joined #evergreen |
| 08:54 |
_bott_ |
tsbere: getting a 404 for the URL provided on a passwd reset under 2.11. Apparently no one had reported the problem over the last few weeks |
| 08:56 |
tsbere |
_bott_: Huh. That sounds odd. Did you customize password_reset.tt2 into oblivion or something? |
| 08:56 |
tsbere |
Or is it a bad/old A/T template? |
| 08:56 |
* tsbere |
fires up a VM to run a clean EG install through to see what happens |
| 08:57 |
_bott_ |
tsbere: stock password_reset.tt2. Ah, template could be! |
| 09:00 |
tsbere |
_bott_: Looks like MVLC's template uses this url and I haven't heard any complaints: https://[% params.hostname %]/eg/opac/password_reset/[% target.uuid %] |
| 09:04 |
_bott_ |
tsbere: yep, that's it. I had a custom A/T template in place from the previous version. |
| 09:04 |
_bott_ |
tsbere: ++ |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:37 |
|
mmorgan joined #evergreen |
| 09:42 |
|
Christineb joined #evergreen |
| 09:59 |
|
jlundgren joined #evergreen |
| 10:30 |
|
maryj joined #evergreen |
| 10:37 |
|
al-muradi joined #evergreen |
| 10:37 |
al-muradi |
hello all |
| 10:38 |
rhamby |
hello! |
| 10:39 |
al-muradi |
trying out a new evergreen installation.. |
| 10:39 |
al-muradi |
seems to work so far. I have a question though.. Is it normal that apache takes sooo long and makes the machine so slow at the beginning? |
| 10:40 |
al-muradi |
i see it starts multiple apache2 -k start processes and take up all the cpu for a while. then after some minutes it stabilizes |
| 10:47 |
rjackson_isl |
good morning! question about lost item returned and voiding of bills. Pre upgrade (on 2.7 ) when void lost item billing when returned and void processing fee on lost item returned were set to true the actual line item bills would be voided. Now it appears that there are system account adjustments to offest those amounts but line item bilss are not voided? |
| 10:48 |
phasefx |
al-muradi: I don't think that's normal. What are the server specs? |
| 10:49 |
kmlussier |
rjackson_isl: If it's for a lost item returned, I think the account adjustments only come into play if the site has enabled the No Negative Balance settings. |
| 10:49 |
csharp |
al-muradi: I've seen that behavior on a server without sufficient RAM |
| 10:50 |
bshum |
I was thinking low RAM too. |
| 10:50 |
kmlussier |
rjackson_isl: There are times when account adjustments are used even if those library settings are not enabled, but it's not for lost item returns. |
| 10:53 |
rjackson_isl |
kmlussier++ |
| 10:53 |
kmlussier |
rjackson_isl: More detail here: http://docs.evergreen-ils.org/2.9/_circulation_4.html. But it looks like those adjustments are always applied, regardless of settings, when overdue fines are adjusted after marking an overdue item lost. |
| 10:57 |
al-muradi |
hey thanks for replies. yes the server we are testing on is a bit weak.. just 3GB of RAM |
| 10:59 |
al-muradi |
but it is a fresh debian installation and nothing else is running on it.. |
| 11:03 |
phasefx |
al-muradi: if you're doing a full stack on one server (database, apache, memcached), then you want it to be beefy. But if you're just playing with it, and aren't going to have multiple concurrent users, then it'll probably be okay |
| 11:04 |
* phasefx |
uses 4GB minimum for his virtual machines |
| 11:06 |
al-muradi |
m. i see.. |
| 11:08 |
al-muradi |
so there is no threads or amounts that one can cut on somewhere in the eg.conf or ejabberd confs.. at least for testing |
| 11:09 |
phasefx |
al-muradi: there's all sorts of tuning one can do, but I don't know what would be best for you given your constraints and your intended uses. The number of Apache children to spawn at startup is configurable |
| 11:09 |
berick |
3G ram is plenty for testing |
| 11:09 |
phasefx |
berick++ |
| 11:10 |
phasefx |
al-muradi: I think the real test is to see how it performs while you're using it |
| 11:10 |
berick |
using a default install, i would expect apache to start up in a matter of seconds on a 3G ram server. if it's not, something is probably not right.. |
| 11:10 |
al-muradi |
why does one need so many apache children, actually? |
| 11:11 |
berick |
al-muradi: how many is it starting? |
| 11:11 |
al-muradi |
berick: then something is not right, any clue how to look for? |
| 11:11 |
al-muradi |
like 18 |
| 11:12 |
berick |
does that include apache2-websockets ? |
| 11:13 |
al-muradi |
hm where do i see that? |
| 11:13 |
berick |
ps ax | grep apache |
| 11:13 |
al-muradi |
no |
| 11:14 |
al-muradi |
they are all apache2 -k start |
| 11:14 |
berick |
i'm currently working on a 2G ram test server. I have 14 total apache processes. half of them are apache-websockets. |
| 11:14 |
berick |
ok |
| 11:14 |
berick |
well, in any event, 18 is more than I would epxect, but it's not that high |
| 11:15 |
berick |
try changing the apache StartServers config to 5, see if that helps at all |
| 11:16 |
al-muradi |
like in the mpm prefork thing |
| 11:16 |
al-muradi |
? |
| 11:16 |
berick |
in /etc/apache2/mods-enabled/mpm_prefork.conf |
| 11:16 |
berick |
yeah |
| 11:19 |
al-muradi |
mmm seems the same |
| 11:20 |
al-muradi |
also memory is still just using 1500mb.. cpu usage is 100% |
| 11:20 |
berick |
hm, ok |
| 11:21 |
berick |
sounds like something is wrong, then. have you tested in 'srfsh' yet? |
| 11:21 |
al-muradi |
it gets stable more quickly now, tho |
| 11:21 |
berick |
so, like phasefx asked.. does it work after it stabililizes? |
| 11:21 |
al-muradi |
just two minutes.. |
| 11:21 |
al-muradi |
yes yes |
| 11:22 |
al-muradi |
will try and add some thousand records |
| 11:22 |
berick |
how many cpu cores? |
| 11:22 |
al-muradi |
to see what happens.. |
| 11:22 |
al-muradi |
2 cores |
| 11:23 |
berick |
hm, 2 cores might have something to do with it. |
| 11:24 |
berick |
i generally use 4 cores for my VM's. haven't tested on 2 in some time. |
| 11:24 |
berick |
don't know how it compares |
| 11:25 |
berick |
when apache first starts, there is a lot of CPU churning |
| 11:27 |
al-muradi |
ah allright. so it might just be that. will try and get a better machine to compare.. |
| 11:27 |
berick |
if raising the cpu core count is not an option, i'd lower StartServers to 2 |
| 11:28 |
berick |
but that may just be offsetting the delay, depending on how busy the test server gets |
| 11:29 |
bshum |
"Some thousand records" to be added... might want more memory down the road too. |
| 11:30 |
bshum |
3 GB is what I'd call bare minimum for concerto-sized test systems. With anything more real, I'd want more memory to avoid weirdness. |
| 11:30 |
|
mmorgan1 joined #evergreen |
| 11:43 |
|
al-muradi joined #evergreen |
| 11:51 |
|
bmills joined #evergreen |
| 12:01 |
|
brahmina joined #evergreen |
| 12:01 |
al-muradi |
uhm and anybody has seen this error before, when logging in with a client? Method [open-ils.storage.actor.org_unit.descendants.atomic] not found for OpenILS::Application::Storage |
| 12:16 |
phasefx |
al-muradi: have you tweaked your org hierarchy at all? or are you using stock concerto test data? |
| 12:17 |
al-muradi |
stock data |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:20 |
phasefx |
al-muradi: this is a little out of date, but it's my general strategy for troubleshooting: https://wiki.evergreen-ils.org/doku.php?id=troubleshooting:checking_for_errors The OpenSRF commands need to replaced with their osrf_control equivalents |
| 12:24 |
phasefx |
cliff notes: stop everything, move or erase logs, start everything, find first error in the logs. If no errors, then try to login again, and search the logs for errors |
| 12:24 |
phasefx |
and try to login with srfsh before trying the staff client |
| 12:44 |
Stompro |
Has anyone seen or created a evergreen check-in flowchart? |
| 12:46 |
al-muradi |
solved, it was some missing perl package |
| 12:46 |
al-muradi |
srfsh was working |
| 12:46 |
al-muradi |
happened before during installation, for some reason some cpan modules were not installed |
| 12:47 |
al-muradi |
thanks a lot for the quick answers. |
| 12:47 |
phasefx |
al-muradi: you're welcome |
| 12:48 |
kmlussier |
al-muradi: I hope your Evergreen testing goes well! |
| 12:48 |
phasefx |
I sometimes think we need to set up mirrors for every dependency, and rig the build process to fallback on those if needed |
| 12:49 |
al-muradi |
I didnt have this problem with the 64 bit version, though |
| 13:04 |
csharp |
al-muradi: 32-bit OSes aren't well-tested nowadays - I think 64-bit is pretty much assumed |
| 13:06 |
al-muradi |
abandonware-ils |
| 13:17 |
bshum |
csharp: "aren't well tested" meaning perhaps, "not tested at all" |
| 13:17 |
bshum |
:) |
| 13:21 |
rhamby |
I think it means "wait, we still release that?" |
| 13:26 |
bshum |
I guess it doesn't explicitly say to use 64-bit editions in the README |
| 13:26 |
bshum |
On the downloads page, it does say that for Ubuntu |
| 14:25 |
kmlussier |
@quote random |
| 14:25 |
pinesol_green |
kmlussier: Quote #31: "<bshum's_prof> You can't build a career around Evergreen" (added by berick at 03:29 PM, September 04, 2012) |
| 14:25 |
bshum |
Oy. |
| 14:25 |
bshum |
That is not a good quote. |
| 14:25 |
bshum |
@quote random |
| 14:25 |
pinesol_green |
bshum: Quote #84: "pinesol_green grabs some Cookies and Cream Ice Cream for Mr. Spock: Something fascinating just happened." (added by bshum at 06:11 PM, May 10, 2014) |
| 14:26 |
bshum |
That one is much better, kmlussier :) |
| 14:26 |
kmlussier |
bshum: Ha! I remember both of those. |
| 14:27 |
kmlussier |
I would rather eat Cookies and Cream Ice Cream than look through Occupational Outlook Handbook to find a new career that doesn't revolve around Evergreen. |
| 14:34 |
* berick |
thought the EG one was funny.. would not be offended if it was removed |
| 14:36 |
bshum |
Nah, it's fine. :) |
| 14:36 |
* kmlussier |
agrees with berick that it was funny. |
| 14:45 |
|
dteston joined #evergreen |
| 16:40 |
|
gmcharlt joined #evergreen |
| 17:02 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 17:03 |
phasefx |
speaking of dependencies... |
| 17:04 |
phasefx |
npm ERR! cb() never called! |
| 17:06 |
|
mmorgan left #evergreen |
| 17:07 |
berick |
who you gonna call? |
| 17:08 |
phasefx |
if there's something strange.. in the qa vm... |
| 17:08 |
berick |
i ain't afraid of no ERR |
| 17:08 |
berick |
but seriously, though, never seen that one |
| 17:08 |
phasefx |
haha |
| 17:12 |
* berick |
squeezes a Hatch conf proposal in just under the wire |
| 17:32 |
|
bmills joined #evergreen |
| 17:53 |
|
bmills joined #evergreen |
| 18:12 |
|
bmills joined #evergreen |
| 18:52 |
|
bmills joined #evergreen |
| 19:37 |
|
sandbergja joined #evergreen |
| 20:20 |
|
bmills joined #evergreen |
| 20:37 |
|
ldw joined #evergreen |
| 23:14 |
* jeff |
stretches "just under the wire" a bit further |
| 23:51 |
jeff |
about 10 minutes to spare by the US/Eastern interpretation of "Friday, January 20, 2017" :-) |
| 23:55 |
dbs |
hey, I just submitted my proposal under the wire! |
| 23:56 |
dbs |
23:43 timestamp :) |
