| Time |
Nick |
Message |
| 07:41 |
|
jboyer-isl joined #evergreen |
| 07:42 |
|
mrpeters joined #evergreen |
| 07:51 |
csharp |
ls |
| 07:51 |
csharp |
bah |
| 07:52 |
csharp |
@later tell jeff thanks for the pointer |
| 07:52 |
pinesol_green |
csharp: The operation succeeded. |
| 08:03 |
csharp |
dbs: we have our memcache set to 6144 MB - probably unnecessarily high, but we wanted it available for caution's sake |
| 08:04 |
csharp |
since we never (/me knocks on wood) have had memcached problems, I've not investigated much further |
| 08:08 |
|
ericar joined #evergreen |
| 08:09 |
|
collum joined #evergreen |
| 08:21 |
|
akilsdonk joined #evergreen |
| 08:35 |
|
julialima_ joined #evergreen |
| 08:36 |
|
RoganH joined #evergreen |
| 08:41 |
|
RoganH joined #evergreen |
| 08:41 |
|
mmorgan1 left #evergreen |
| 08:42 |
|
abowling joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:53 |
dbs |
csharp: thanks! looks like browse is just timing out in the database on "SELECT * FROM metabib.browse( 'title', 'mines', '117', NULL, 'f', NULL, '10' ) AS "metabib.browse";" for that one OU for some reason |
| 08:54 |
|
Shae joined #evergreen |
| 08:54 |
* dbs |
will dig a bit further |
| 08:55 |
|
Dyrcona joined #evergreen |
| 09:18 |
|
krvmga joined #evergreen |
| 09:21 |
krvmga |
in our opac, in the advanced search screen, our format filters box has suddenly is no longer populated. i don't know why. |
| 09:24 |
kmlussier |
krvmga: What should be populating that box? The default formats that shipped with Evergreen 2.5 or did you have search filter groups there? |
| 09:24 |
kmlussier |
krvmga: Also, I see a similar problem on your basic search page. |
| 09:25 |
krvmga |
kmlussier: we're wondering if autogen needed to be run after some work that was done over the weekend |
| 09:25 |
krvmga |
we're doing that now |
| 09:25 |
krvmga |
kmlussier: we have a custom config for the format filter box that points to the format_filters that we use. |
| 09:27 |
kmlussier |
krvmga: So I'm guessing that would be search filter groups since you aren't on an MVF release yet? |
| 09:27 |
krvmga |
kmlussier: yes, we aren't on an MVF release yet. and yes, it's search filter groups |
| 09:28 |
krvmga |
apparently some changes were made to fm_IDL.xml over the weekend but i didn't think that would mess this up. |
| 09:30 |
|
yboston joined #evergreen |
| 09:31 |
krvmga |
i hate it when i come in and find something has been working has suddenly stopped working :( |
| 09:33 |
Dyrcona |
krvmga: Always run autogen.sh after changing fm_IDL.xml. |
| 09:34 |
krvmga |
Dyrcona: thanks. i think that got skipped when the changes were made. |
| 09:34 |
Dyrcona |
krvmga: That happens a lot. ;) |
| 09:35 |
* Dyrcona |
goes off tilting at windmills. |
| 09:39 |
krvmga |
Dyrcona: unfortunately, that doesn't seem to have fixed the issue. :( |
| 09:40 |
Dyrcona |
Hmm. Probably a syntax problem somewhere, but I don't know where to look off the top of my head. |
| 09:42 |
csharp |
hmmm - I'm getting posgresql syntax errors around series searches: http://pastie.org/9843687 |
| 09:43 |
kmlussier |
krvmga: Did you see my pm? |
| 09:45 |
csharp |
eeevil: if you get a chance, would you mind looking at the paste I just posted? |
| 09:47 |
eeevil |
csharp: what's the actual search string |
| 09:47 |
csharp |
eeevil: I don't see it in the activity log :-( |
| 09:48 |
eeevil |
you've managed to convince QP to pass a []-enclosed string all the way down to the db, it seems |
| 09:48 |
csharp |
if I can get Elaine on it, maybe she can recreate |
| 09:48 |
csharp |
eeevil: I'll look into it and let you know |
| 09:49 |
eeevil |
I'll bet it's something like "programs for children series_title[PBS Kids]" |
| 09:51 |
dbs |
metabib.browse() Total runtime: 942310.511 ms -- for that one library. 5700ms if I run it for a different library. what the... |
| 09:51 |
dbs |
Possibly horribly sparse visible browsable results for that one library? |
| 09:52 |
eeevil |
csharp: it doesn't look like you currently have series|series_title set as a facet, but someone is probably using either a bookmark or maybe the kpac to add that to searches. You'll need to add that back as a facet |
| 09:53 |
eeevil |
or stop using it in links ... which is not easy, of course |
| 09:54 |
csharp |
eeevil: |
| 09:55 |
csharp |
eeevil: ok |
| 09:55 |
csharp |
:-) |
| 09:55 |
csharp |
thanks |
| 09:55 |
dbs |
I guess people can trigger postgresql syntax errors with quasi-arbitrary GET params. |
| 09:55 |
eeevil |
dbs: they sure can ... but this happens to not be arbitrary ;) |
| 09:56 |
dbs |
We could maybe be defensive, load up the configured facets / OUs / search fields and filter before passing on to the db I guess |
| 10:00 |
eeevil |
dbs: we do that ... but obviously not well enough for all cases |
| 10:06 |
* dbs |
clearly needs to step through the constituent parts of metabib.browse() to find the bottleneck |
| 10:07 |
krvmga |
does autogen clear the cache on the server? |
| 10:08 |
* krvmga |
wondered if the format filters not displaying was a cache problem after autogen was run a little while ago |
| 10:09 |
kmlussier |
krvmga: I was just looking back on logs when I encountered a similar problem. At the time, reloading apache loaded the search filter groups. |
| 10:10 |
krvmga |
thanks. we can try that. |
| 10:10 |
kmlussier |
In my case, the entries weren't displaying immediately after I created the filter groups. |
| 10:10 |
kmlussier |
It seems odd that it would need to be done again for existing filter groups. |
| 10:11 |
krvmga |
yes, it does seem odd. but maybe it's worth a try. |
| 10:13 |
kmlussier |
krvmga: Also, reading further down in the log where reloading apache was recommended, I see it didn't fix the problem. :-/ |
| 10:14 |
krvmga |
kmlussier: pooh |
| 10:14 |
Dyrcona |
krvmga: autogen does not clear the cache on the server. |
| 10:14 |
krvmga |
Dyrcona: thanks |
| 10:15 |
Dyrcona |
If it did, it would destroy all of the logged in sessions. |
| 10:16 |
* krvmga |
sees strong positive value in not destroying all the logged in sessions. :) |
| 10:18 |
mmorgan |
krvmga: I recall a few cases in the past where we have seen the same problem with an empty format box. Sadly, I can't offer a solution, but we did find that the problem went away overnight. Seems to suggest a caching problem somewhere. |
| 10:19 |
krvmga |
mmorgan: thanks |
| 10:26 |
krvmga |
clearing the server cache: does that mean flushing the memcached server? |
| 10:26 |
krvmga |
will this not wipe out logged in sessions? |
| 10:26 |
|
RoganH joined #evergreen |
| 10:26 |
jeff |
if you clear/flush memcached, you will invalidate every logged in session. |
| 10:28 |
|
jwoodard joined #evergreen |
| 10:28 |
krvmga |
i'm not sure which cache to clear. :( |
| 10:37 |
jboyer-isl |
krvmga, you almost never need to clear the memcached cache, but Apache keeps a local cache on each machine that's wiped out on a 'service apache2 restart', and of course staff clients also have local caches. (restart or Admin/Developer menu option to clear) |
| 10:37 |
jboyer-isl |
That's not to say that either of those things will fix your issue. :( |
| 10:38 |
krvmga |
jboyer-isl: thanks |
| 10:39 |
jeff |
jboyer-isl: are you referencing the various in-process mod_perl bits there, or some other more specific "cache"? |
| 10:44 |
Dyrcona |
Does OpenILS/Application/PermaCrud.pm actually serve any purpose? |
| 10:45 |
Dyrcona |
I haven't found any other code that uses it, and it appears to create cstore transactions that will not be closed if the code ever is called, at in search_permacrud. |
| 10:45 |
|
rjackson-isl joined #evergreen |
| 10:45 |
berick |
Dyrcona: it's used in a few places (vandelay.js), but it's effectively deprecated |
| 10:45 |
berick |
+1 to getting rid of it if feasible |
| 10:46 |
Dyrcona |
berick: Thanks. |
| 10:46 |
jeff |
vandelay, serials, and... Open-ILS/web/js/dojo/openils/widget/TranslatorPopup.js? |
| 10:46 |
Dyrcona |
I only checked the other perl modules... |
| 10:46 |
Dyrcona |
but I didn't check for it as a service. |
| 10:47 |
jeff |
it's the implementation of the (mostly-deprecated, as berick noted) open-ils.permacrud service. |
| 10:47 |
Dyrcona |
Yep. |
| 10:47 |
jboyer-isl |
jeff: Yes. I'm assuming there's some stuff in-memory for the perlmods loaded on apache startup and apache possibly caching things that may have a non-0 cache lifetime. (though there may not be many of those that matter) |
| 10:48 |
jeff |
jboyer-isl: pretty sure there are a few -- just wanted to make sure you weren't referencing something else :-) |
| 10:49 |
berick |
Dyrcona: oh, think that's the source of your cstore proliferation? |
| 10:49 |
jboyer-isl |
Well, I suppose that restarting a large service like apache could cause some FS cache churn, but I wouldn't count on that. ;) |
| 10:49 |
Dyrcona |
berick: Not necessarily, but I've started checking everything that does xact=>1 with new editor. |
| 10:50 |
Dyrcona |
PermaCrud has a couple of troubling bits, so it could be contributing. |
| 10:53 |
Dyrcona |
I'm not finding any open-ils.permacrud calls in the log, except for ones that actually call opensrf.system.echo.atomic. |
| 10:54 |
jboyer-isl |
LP lets me down again. Does anyone know if you can create a copy location and then immediately create items in it (in the same staff client session)? I was thinking that the xul copy editor may be using the cached list of acpl |
| 10:54 |
jboyer-isl |
's from login, not going to the DB each time (like some of the TT2 based interfaces clearly do, since you can see the new locations) |
| 10:54 |
jboyer-isl |
Basically, do you need to restart the client to create items in a brand new location? |
| 10:55 |
Dyrcona |
jboyer-isl: I seem to recall that you do have to restart the client. |
| 10:55 |
bshum |
That sounds right to me too. |
| 10:55 |
tsbere |
Or at least log out and back in again |
| 10:56 |
jboyer-isl |
Excellent. that was my assumption, but I wanted to verify it real quick. |
| 11:06 |
csharp |
eeevil: that appears to have been the issue - Terran added back the facet and I'm no longer seeing the error |
| 11:07 |
|
julialima_ joined #evergreen |
| 11:11 |
krvmga |
just for the record: rolling our brickheads fixed the problem with format filters not showing up. i'm not sure what caused the problem to begin with. |
| 11:14 |
kmlussier |
krvmga: Thanks for reporting back! |
| 11:16 |
krvmga |
additional note, apparently some services weren't started correctly after work done on the weekend. |
| 11:21 |
krvmga |
start-all was used for drones instead of start-services |
| 11:22 |
krvmga |
LPT: if you accidentally do start-all instead of start-services, stop-all and start over. |
| 11:22 |
krvmga |
heartfelt thanks to our great support! :) |
| 11:23 |
bshum |
That sounds weird. |
| 11:24 |
bshum |
But I haven't run separate drones in awhile... I would have expected brick_ctl.sh to deal with stuff like that. |
| 11:24 |
csharp |
hmm - offline patron list download is 404-ing, but the file is there: /openils/var/data/offline/blocked/patron-blocked-list.2015-01-20.txt |
| 11:24 |
krvmga |
bshum: what i know about this might fill a thimble. |
| 11:24 |
krvmga |
and i may be flattering myself there. |
| 11:25 |
bshum |
csharp: With the date like that? |
| 11:25 |
* bshum |
didn't think it had dates attache |
| 11:25 |
bshum |
*attached |
| 11:25 |
csharp |
yep - the way we've always done it |
| 11:25 |
csharp |
I know nothing we're doing has changed since 2.1 |
| 11:25 |
|
nhilton joined #evergreen |
| 11:26 |
bshum |
csharp: Does apache say anything? |
| 11:26 |
bshum |
In terms of what the 404 requested page was |
| 11:26 |
|
ericar joined #evergreen |
| 11:27 |
jeff |
you might be missing apache config bits related to access control of that data... and you might also have had a process that was copying things from the date-based to another? :-) |
| 11:27 |
bshum |
Heh jeff++ |
| 11:29 |
dbs |
Hmm. Hold capture delayed. "This item could fulfill a hold request but capture has been delayed by policy." |
| 11:29 |
* dbs |
doing lots of catch-up with 2.4-2.7 changes |
| 11:29 |
jeff |
that's a boolean on asset.copy_location |
| 11:29 |
jeff |
new in 1.2.0.4, I think ;-) |
| 11:30 |
Dyrcona |
dbs: Do you use booking? |
| 11:30 |
* Dyrcona |
is just curious. |
| 11:31 |
dbs |
Dyrcona: we tried, once upon a time, but gave up |
| 11:31 |
dbs |
no auditor table on asset.copy_location here so I can't see when that changed |
| 11:32 |
Dyrcona |
dbs: OK. I asked mainly 'cause it appears to be riddled with dangling database transactions. |
| 11:32 |
Dyrcona |
It creates cstoreditors with xact=>1 and later calls disconnect, but disconnect doesn't do a rollback or commit. |
| 11:33 |
* Dyrcona |
praises C-x n d |
| 11:33 |
dbs |
Dyrcona++ |
| 11:34 |
dbs |
hunting the open db xacts |
| 11:34 |
csharp |
[20/Jan/2015:11:33:33 -0500] "GET /standalone/list.txt HTTP/1.1" 404 3654 |
| 11:34 |
csharp |
bshum: ^^ |
| 11:34 |
csharp |
that's obviously not what the file is called |
| 11:34 |
bshum |
csharp: Yeah so maybe jeff is right |
| 11:34 |
csharp |
jeff: ahhh |
| 11:34 |
bshum |
That's what I thought we named the file on our systems |
| 11:34 |
csharp |
argh |
| 11:34 |
jeff |
i'm not aware of anything in the staff client that ever used a date in the request. you could probably verify with your historical apache access logs. |
| 11:34 |
bshum |
So I was surprised by the styling of yours |
| 11:35 |
csharp |
if it's not one thing, it's another |
| 11:35 |
dbs |
missing cp or ln mebbe? |
| 11:39 |
csharp |
aw man |
| 11:39 |
csharp |
it's changed SSH host keys |
| 11:39 |
csharp |
@eightball is it possible THAT SOMEONE IS DOING SOMETHING NASTY? |
| 11:39 |
pinesol_green |
csharp: Maybe... |
| 11:40 |
berick |
heh |
| 11:47 |
dbs |
and of course opportunistic hold capture works fine when I try it myself. now to see if it's a permission thing. |
| 11:48 |
bshum |
So, some fun this morning with lost and paid status. It looks like a situation occurred where an item was checked out, went overdue, generated some overdue fines, was renewed (2nd transaction) |
| 11:48 |
bshum |
Then it went to lost |
| 11:48 |
bshum |
And when they went to pay off the first transaction's overdues |
| 11:48 |
bshum |
It might have marked the item as "lost and paid" |
| 11:48 |
bshum |
Even though the 2nd transaction still has a pending lost bill on it |
| 11:49 |
bshum |
We're still investigating, but I might be opening an LP on that. |
| 11:50 |
kmlussier |
Wait, what? They renewed an overdue transaction and it went to Lost? Did I understand that correctly? |
| 11:51 |
Dyrcona |
They probably renewed a lost. |
| 11:51 |
Dyrcona |
lost-- |
| 11:51 |
dbs |
Lost was not renewed for another season |
| 11:51 |
kmlussier |
But you can't renew a lost. You get that terrible error message. |
| 11:52 |
Dyrcona |
Erm, well, I "fixed" that, IIRC. |
| 11:52 |
mmorgan |
I read it as the *second* transaction went to lost. |
| 11:52 |
kmlussier |
Dyrcona: That branch still had bugs in it, so it never went into core. |
| 11:54 |
bshum |
mmorgan is correct, the second transaction went to lost. |
| 11:54 |
bshum |
The first one was just renewed, so it should have ended |
| 11:54 |
bshum |
But paying the overdues on the first transaction caused the item to go into a lost and paid state. |
| 11:55 |
bshum |
They didn't touch the lost bill or the lost transaction |
| 11:55 |
bshum |
it is still open |
| 11:55 |
mmorgan |
Yeah, but did the first transaction get a finish date when it was renewed since there were overdue charges? |
| 11:55 |
bshum |
That's what I'm checking now |
| 11:55 |
bshum |
It's from 2014, so it should have. |
| 11:55 |
bshum |
But "should" is an evil thing |
| 11:56 |
dbs |
right up there with "in theory" |
| 11:58 |
bshum |
Huh.... |
| 11:58 |
bshum |
The xact_finish on the first transaction is the date that the item was paid |
| 11:58 |
bshum |
So maybe it didn't have a proper end date for some reason. |
| 11:58 |
bshum |
That's super weird. |
| 11:58 |
bshum |
I thought renewing an item would close the transaction |
| 11:59 |
jeff |
my understanding is that (barring various bugs over the years both ways) renewing an item with a balance owed will not close the tranaction. |
| 12:00 |
jeff |
because while the item is indeed "checked in" in the scope of that one circ, there is money owed. |
| 12:00 |
bshum |
And hmm |
| 12:00 |
* mmorgan |
agrees with jeff |
| 12:00 |
bshum |
Yeah that makes sense I guess... |
| 12:03 |
bshum |
Well then that sounds like that's how the bug happens |
| 12:03 |
bshum |
If the transaction is being closed for the first time, because we're finally paying off the fines from a previous transaction |
| 12:04 |
jboyer-isl |
csharp, I looked through our config and the example files in git, and we don't have any reference to the blocked list. (We don't use it, but I would have set it up, just in case). The only reference to list.txt anywhere is in the crontab.example. |
| 12:04 |
bshum |
but the item is in a state of "lost" presently (from other later transactions) |
| 12:04 |
bshum |
And the org unit setting is set |
| 12:04 |
bshum |
It'll kick the item into "lost and paid" |
| 12:04 |
jboyer-isl |
I don't know where it's referenced (unles it's hard coded into the client) |
| 12:04 |
jboyer-isl |
Oh, I suppose so: xul/staff_client/chrome/content/main/menu.js: var url = 'https://' + XML_HTTP_SERVER + '/standalone/list.txt'; |
| 12:06 |
jboyer-isl |
So you probably do just need a ln somewhere, unless you've been customizing your clients to do something else. |
| 12:08 |
mmorgan |
bshum: How long have you had the Lost and Paid org unit setting set? |
| 12:08 |
bshum |
mmorgan: I'd have to check our org unit setting history to know exactly, but not longer than the last two months or so |
| 12:11 |
mmorgan |
bshum: ok, thanks. We haven't implemented it yet, but will very soon. |
| 12:11 |
bshum |
mmorgan: I think the biggest gripe we've had so far is that people still want to delete the item from the system. |
| 12:11 |
bshum |
Especially now that they see it's "lost and paid" |
| 12:12 |
bshum |
But the permission is still a broad, copy in bad status override |
| 12:12 |
bshum |
Which would allow them to delete any copy they wanted. |
| 12:12 |
mmorgan |
We're actually planning on NOT delete restricting the lost and paid status. |
| 12:13 |
mmorgan |
Book's paid for, and no longer on the patron record, so out it goes! |
| 12:13 |
bshum |
mmorgan: That's nice, in theory. |
| 12:13 |
bshum |
If you figure out how to do it without giving staff the ability to delete other materials, like lost, longoverdue, etc. let me know. |
| 12:13 |
bshum |
I don't think it's granular enough for that. Yet. |
| 12:14 |
bshum |
I believe we need further development there to make the permissions more precise to allow for that possibility of deleting a lost and paid copy, but not a lost one. |
| 12:18 |
mmorgan |
I was planning on changing the restrict_copy_delete flag in config.copy_status to false. |
| 12:19 |
bshum |
mmorgan: Hmm, that sounds like it might work :) |
| 12:19 |
Dyrcona |
mmorgan++ |
| 12:19 |
bshum |
mmorgan++ |
| 12:20 |
bshum |
Filed: https://bugs.launchpad.net/evergreen/+bug/1412893 |
| 12:20 |
pinesol_green |
Launchpad bug 1412893 in Evergreen "Applying lost and paid status at the wrong time" (affected: 1, heat: 6) [Undecided,New] |
| 12:20 |
mmorgan |
can't think of a reason for anyone *not* to delete the lost and paids. |
| 12:21 |
Dyrcona |
senator++ # For line 374 of OpenILS::Application::Acq::Invoice |
| 12:22 |
* bshum |
wants "easy_money" |
| 12:23 |
mmorgan |
bshum++ |
| 12:24 |
|
yboston joined #evergreen |
| 12:24 |
bshum |
Dyrcona: I wonder if maybe if we added a check to say, only run the block for marking an item lost and paid if the transaction itself has a stop fines of lost or longoverdue |
| 12:25 |
bshum |
But that assumes that those transactions will definitely have that status |
| 12:25 |
* bshum |
wonders what the status of circs that are manually marked vs. automatically |
| 12:25 |
bshum |
Or if an item hits maxfines, and then is later marked lost manually |
| 12:25 |
bshum |
I would think the stop_fines doesn't get substituted in that case. |
| 12:26 |
bshum |
If there wasn't an automated switchover |
| 12:29 |
* bshum |
tries to think of other pitfalls in specifying based on the stop_fines reason. |
| 12:29 |
bshum |
Circulation and billings are so complicated :( |
| 12:29 |
Dyrcona |
Yes. |
| 12:30 |
* mmorgan |
agrees with bshum :-( |
| 12:30 |
csharp |
jboyer-isl: thanks - the script runs on the utility server and scp's files to the right location/filename on each brick head - I just hadn't updated my .ssh/known_hosts file so all of them were refusing to connect |
| 12:31 |
mmorgan |
Seems like there are too many places to look when trying to determine the true status of a transaction. |
| 12:31 |
jboyer-isl |
I see. I thought your message above meant that you were getting an error when ssh'ing in to the machine, I didn't realize that was the cause of the issue. Makes sense. |
| 12:32 |
Dyrcona |
mmorgan: And some things happen more than once during a transaction. |
| 12:32 |
* csharp |
will have to read this scrollback sometime later |
| 12:32 |
mmorgan |
Yes, many more times than once ;-) |
| 12:35 |
Stompro |
mmorgan: I think we have people that pay for items that are lost, then find them later and want a refund. Would that be a reason to not delete? |
| 12:36 |
bshum |
Stompro: That'd be mainly a problem if the library then wanted to just start reusing that barcoded material again. |
| 12:36 |
bshum |
Since the barcode would no longer exist. |
| 12:36 |
mmorgan |
Stompro: It may be. I should have said in our system :). |
| 12:37 |
mmorgan |
Refunds are generally not automatic in our libraries. |
| 12:38 |
|
ericar joined #evergreen |
| 12:40 |
Dyrcona |
Most of our members do not issue refunds. |
| 12:40 |
Dyrcona |
Once the patrons has paid, it is their book. |
| 12:40 |
Dyrcona |
But lost stuff shows up all the time. |
| 12:41 |
jeff |
"thank you for your kind donation to the library" |
| 12:41 |
jeff |
(of your book) |
| 12:47 |
Dyrcona |
heh |
| 13:16 |
|
jihpringle joined #evergreen |
| 14:51 |
|
mrpeters left #evergreen |
| 14:54 |
kmlussier |
It always gives me a fuzzy, warm feeling to see a happy Evergreen user - https://www.facebook.com/EvergreenILS/posts/788352871250712?notif_t=wall |
| 14:55 |
bshum |
:) |
| 15:10 |
|
RoganH joined #evergreen |
| 15:18 |
|
rangi joined #evergreen |
| 15:27 |
|
ericar_ joined #evergreen |
| 15:36 |
* dbs |
tries removing timeout="60" from oils_sip.xml to see if that prevents the self-check from reporting connection failures every 60 seconds. heh. |
| 16:06 |
dbs |
ding ding ding |
| 16:06 |
dbs |
The timer on my phone finally got past 60 seconds without seeing the self-check report a connection error. |
| 16:07 |
dbs |
seems to be included in the examples for both oils_sip.xml and SIPconfig.xml |
| 16:14 |
|
kbutler joined #evergreen |
| 16:16 |
jeff |
dbs: this is the one in acsconfig/institutions/institution/policy? |
| 16:17 |
jeff |
(and not the one in acsconfig/listeners/service) |
| 16:20 |
|
RoganH joined #evergreen |
| 16:22 |
dbs |
service |
| 16:24 |
dbs |
seems to take priority: my $timeout = $self->{service}->{timeout} || $self->{config}->{timeout} || 0; |
| 16:30 |
|
nhilton_ joined #evergreen |
| 17:02 |
|
nhilton joined #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 18:32 |
|
sandbergja joined #evergreen |
| 18:33 |
|
sandbergja joined #evergreen |
| 19:01 |
|
buzzy joined #evergreen |
| 23:23 |
|
akilsdonk joined #evergreen |
