| Time |
Nick |
Message |
| 08:06 |
|
agoben joined #evergreen |
| 08:08 |
csharp |
@weather 30033 |
| 08:08 |
pinesol_green |
csharp: Decatur, GA :: Overcast :: 61F/16C | Friday: Windy. Cloudy skies will become mostly sunny this afternoon. Cooler. High 67F. Winds NW at 20 to 30 mph. Friday Night: Clear skies. Cooler. Low 47F. Winds NW at 10 to 20 mph. |
| 08:08 |
csharp |
that's more like it |
| 08:14 |
tsbere |
@weather |
| 08:14 |
pinesol_green |
tsbere: North Andover, MA :: Fog :: 60F/16C | Friday: Cloudy with occasional rain showers. Thunder possible. High 71F. Winds SE at 5 to 10 mph. Chance of rain 70%. Friday Night: Thunderstorms this evening followed by occasional showers overnight. Low around 60F. Winds NNE at 5 to 10 mph. Chance of rain 90%. Rainfall near an inch. |
| 08:17 |
jeff |
@weather ktvc |
| 08:17 |
pinesol_green |
jeff: Cherry Capital, MI :: Light Rain :: 45F/7C | Friday: Mostly cloudy. Slight chance of a rain shower. High 49F. Winds N at 10 to 15 mph. Friday Night: Considerable cloudiness. Low 39F. Winds N at 5 to 10 mph. | Updated: 24m ago |
| 08:18 |
jeff |
"considerable cloudiness" |
| 08:40 |
csharp |
@band add Considerable Cloudiness |
| 08:40 |
pinesol_green |
csharp: As great as you are man, you'll never be greater than yourself. |
| 08:42 |
gmcharlt |
quick heads up - part or all of Dyn.com's DNS services are experiencing a DDoS |
| 08:43 |
gmcharlt |
and this might effect resolution of evergreen-ils.org -- will be curious to know whether anybody is experiencing difficulties there |
| 08:43 |
tsbere |
gmcharlt: Quick test tells me that yes, I am experiencing difficulties there |
| 08:44 |
jeff |
resolves immediately for me. |
| 08:45 |
tsbere |
I don't think anyone here has requested the domain for a few days, thus making it so that our DNS server's cached entries expired |
| 08:45 |
jeff |
also immediate nxdomain as appropriate when requesting a non-existant host within the domain. |
| 08:47 |
jeff |
i'm fairly certain that the Dyn nameservers are anycasted, so that introduces a huge YMMV factor. i'm not even sure that individual data points here of success/fail are going to be very useful. :-) |
| 08:48 |
tsbere |
jeff: I say "any data points of fail are useful as it tells us some people *will* be having a problem, and we know what to tell them" ;) |
| 08:49 |
jeff |
okay, okay. s/individual data points/further individual data points/ perhaps. :-) |
| 08:49 |
|
bos20k joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:10 |
Dyrcona |
So, SIPServer question.... With Socket::Linux installed, it looks like SIPServer gets a 2 minute timeout on idle TCP connections? |
| 09:12 |
jeff |
I can look and test, but: is there an additional question lurking in the shadows? |
| 09:14 |
tsbere |
Dyrcona: I think it might also depend on timeout values in the SIP config, but without knowing why you are asking... |
| 09:15 |
jeff |
Dyrcona: if you're basing the question off of the setsockopt() call that sets TCP_KEEPIDLE to 120 -- that's (i did have to look it up) " The time (in seconds) the connection needs to remain idle before TCP starts sending keepalive probes, if the socket option SO_KEEPALIVE has been set on this socket." |
| 09:15 |
Dyrcona |
jeff | tsbere: I think I misunderstood the TCP_KEEPIDL option. I now think that corresponds to tcp_keepalive_time, yes? |
| 09:16 |
jeff |
i guessed correctly! hooray! |
| 09:16 |
Dyrcona |
jeff: Heh, what I just said. |
| 09:17 |
Dyrcona |
Before I looked it up, I thought it might be an idle timeout (as in drop the connection if idle for x seconds), but that didn't quite make sense with the other settings. |
| 09:17 |
|
bos20k joined #evergreen |
| 09:17 |
Dyrcona |
I'm asking because, we set the other timeouts to 0. |
| 09:17 |
Dyrcona |
Some libraries were still complaining that their self checks were getting disconnected. |
| 09:18 |
Dyrcona |
So, I installed Socket::Linux to get the keep alive packet settings. |
| 09:18 |
Dyrcona |
I did this on Wednesday. |
| 09:18 |
Dyrcona |
Every night, one of the support staff sends an email with number of running SIPServers. |
| 09:18 |
Dyrcona |
That's normally about 80 per server. |
| 09:19 |
|
book` joined #evergreen |
| 09:19 |
Dyrcona |
Last night, the numbers were from 19 to 27 per server. |
| 09:20 |
|
yboston joined #evergreen |
| 09:20 |
Dyrcona |
I was a little surprised that enabling keep alive dropped the number of SIPServers running, but it could be an anomaly related to something else. |
| 09:22 |
jeff |
your change may have enabled detection and elimination of otherwise dead and lingering (but not in the SO_LINGER sense!) connections. |
| 09:23 |
|
maryj joined #evergreen |
| 09:23 |
Dyrcona |
Yeah, that's what I'm thinking. That something else was enabled by that change. |
| 09:23 |
Dyrcona |
To me, that's a good thing, but I'm sure that I'll get questions because the numbers are different. :) |
| 09:24 |
Dyrcona |
I've asked the support staff to check with the libraries that reported problems to see if things improved or not. |
| 09:24 |
jeff |
yup. |
| 09:24 |
miker |
that's exactly it |
| 09:24 |
miker |
detection of client-side-dead sessions |
| 09:25 |
miker |
where a firewall drops connection tracking, say, or the client just goes away without shutting down the socket |
| 09:28 |
Dyrcona |
Yeah, and I've been asked to remove the module. :( |
| 09:28 |
Dyrcona |
At this point, I've said there's nothing we can do about the disconnects. |
| 09:28 |
Dyrcona |
It's a firewall or router between us and them dropping idle connections. |
| 09:29 |
Dyrcona |
Also, self check vendors should not write software that expects to keep a single tcp connection open all day. |
| 09:30 |
miker |
I know you know, but removing the module won't make the clients stay connected, it just won't let you know they've dropped (and waste RAM) |
| 09:31 |
Dyrcona |
And, I'm using webchat because my client refuses to work with SASL and freenode. |
| 09:31 |
Dyrcona |
Yeah, but the people I work for don't.... |
| 09:31 |
Dyrcona |
Maybe I'll try and convince them. |
| 09:36 |
Dyrcona |
I suppose that I could try lowering the TCP_KEEPIDL setting. Could be that some firewall is being overly aggressive by dropping idle connections after a minute or so? |
| 09:46 |
Dyrcona |
The git server/monitor is the only one that I can access directly. |
| 09:46 |
Dyrcona |
Oops... Meant that for a private chat. :) |
| 09:51 |
miker |
Dyrcona: I've seen that before (aggressive dropping). IIRC, you should be able to control TCP_KEEPIDL and friends with env vars at sipserver start time |
| 09:52 |
Dyrcona |
miker: The values to the setsockopt call are hard coded in the Perl. I'll see if it reads the environment and if that could override the hardcoded options. |
| 09:53 |
miker |
ah. well, probably not... |
| 09:56 |
Dyrcona |
Nope. Doesn't use the environment internally, and if it did, I'd expect options to override the environment. |
| 09:57 |
Dyrcona |
Woudn't be hard to do that: $tcp_keepidl_val = $ENV{TCP_KEEPIDL} || 120; |
| 09:59 |
tsbere |
Dyrcona: At that point I would be tempted to just add to the config file. Or make a local customization. |
| 09:59 |
gmcharlt |
Dyn is saying that they've mitigated the DDoS, by th eway |
| 10:00 |
Dyrcona |
Well, the quick thing is to make a local customization. New config options would be the way to go for a working/enhancement branch. |
| 10:00 |
tsbere |
gmcharlt: And, testing again, I can load things now. So yay! |
| 10:01 |
* Dyrcona |
wonders if the DDOS had to do with the SASL authentication failures... |
| 10:01 |
Dyrcona |
Or is that not to do with Freenode this time? |
| 10:02 |
tsbere |
DNS DDOS was causing issues with evergreen-ils.org for some percentage of the internet |
| 10:02 |
berick |
kicking around the idea of a best-match option for authority linking. e.g. bib has [650 $a Zombies $v Drama], but we only have an auth for [150 $a Zombies]. wondering if this has come up before (or is in some way supported) and I'm just missing it. |
| 10:02 |
Dyrcona |
OK. I realized that was more likely after I hit enter. :) |
| 10:03 |
|
gmcharlt joined #evergreen |
| 10:13 |
|
collum joined #evergreen |
| 10:48 |
|
cgreen joined #evergreen |
| 11:15 |
|
cgreen joined #evergreen |
| 11:21 |
|
dans-datalogics joined #evergreen |
| 11:30 |
|
jvwoolf joined #evergreen |
| 11:36 |
cgreen |
Hello, all -- we have an Ubuntu server running Evergreen and the database, and it's lately been acting flaky when one tries to log in or connect to Evergreen. "Re-test[ing] the server" on the web client sometimes takes ages to successfully verify; other times, the server returns a 500 Internal Server Error. We have noticed that it tends to use up quite a bit of memory on our server, even though we have met or exceeded the recommend |
| 11:36 |
cgreen |
It was working well for a week or so. Is there a configuration we may have incorrectly set? Any insight is appreciated, and thank you! |
| 11:37 |
|
Christineb joined #evergreen |
| 11:40 |
miker |
berick: for human use, it works close to that. it drops you into the authority list as close to the bib value as possible. your example should be usable. but, you're talking about machine matching, aren't you :) |
| 11:41 |
miker |
(and not blowing away $v Drama, as well, I suppose) |
| 11:42 |
miker |
IOW, control $a, but leave $v alone as "bib-only" data not controlled by the specific auth record |
| 11:42 |
miker |
(unless the auth records grows a $v in the future) |
| 11:42 |
berick |
miker: exactly |
| 11:43 |
berick |
link to shorter record, if a new record arrives including the $v, then link to that instead |
| 11:44 |
miker |
I think it's been thought about. the stored proc that updates bibs would need to be made smarter, I think, to avoid killing the $v on unrelated auth update |
| 11:46 |
dbwells |
I thought at one time the intention was for the placement of subfield $0 to determine the "depth" of control. But this is memory from way, way back, and maybe not exactly related. |
| 11:48 |
miker |
dbwells: I don't recall that... but it doesn't mean that wasn't considered |
| 11:49 |
phasefx |
cgreen: you have Evergreen and the database running on the same server? 500 Internal Server errors should produce useful information in the Apache logs |
| 11:50 |
berick |
miker: right... that's a concern |
| 11:51 |
berick |
dbwells: interesting.. "depth" certainly captures the idea |
| 11:54 |
dans-datalogics |
phasefx: i'm working with cgreen. at this precise moment, the client's status check is returning 200s. logging in with our admin credentials is failing. which logs (and what logging level) might give us the best info for that? |
| 11:54 |
|
brahmina joined #evergreen |
| 11:56 |
phasefx |
dans-datalogics: all logins failing or just the admin one? |
| 11:57 |
dans-datalogics |
phasefx: as far as i know, we just have this one account to log into the staff client at the moment. |
| 11:58 |
cgreen |
phasefx: All logins fail in the srfsh shell |
| 11:58 |
dbwells |
berick: The whole concept of freefloating subvisions is just problematic for basic lookup-style control, but I have a pretty cursory understanding of any confining rules which might apply to them to make control more feasible. And yeah, the discussion I specifically recall was the '10 conference, so that was a bit ago :) |
| 11:59 |
dans-datalogics |
phasefx: for what its worth, i see a Jabber error after a failed login attempt in openils/gateway.log -- "no one to send my message to!" |
| 12:00 |
|
bmills joined #evergreen |
| 12:00 |
csharp |
dans-datalogics: might be worth setting up your logs to go to a central directory/server: https://docs.google.com/document/d/1BJ7kSr5LfPkxXRhcrYjNyPlbT9PlNFHg6zL-tyetnKA/edit |
| 12:00 |
phasefx |
dans-datalogics: this isn't something you would normally do on a production system, but if you're the only user, I would shut down OpenSRF and stop Apache. Make sure memcached and postgres are running. The log files are typically at /openils/var/logs/, I would move the existing *.log files out of the way (into old/) or something like that. Then start up OpenSRF. grep all the logs for ERR |
| 12:00 |
phasefx |
If no errors, then start Apache, grep the logs again.Then, tail the opensrf.sys log, and try to login |
| 12:01 |
phasefx |
*memcached, ejabberd, and postgres, that is |
| 12:01 |
miker |
dbwells / berick: not sure if this is something you'd see in the wild, but: bib with $a $x $v; authority with $a $v ... depths don't match, but with smarts, we could control only what the authority /has/ |
| 12:02 |
|
Dyrcona joined #evergreen |
| 12:08 |
berick |
miker: yeah, that's where things take an interesting turn.. scoring the matchy-ness of two fields that are not identical. |
| 12:08 |
dans-datalogics |
phasefx: we'll do that and see what we can see |
| 12:11 |
berick |
a suggestion that came up here was in effect to perform a left-anchored substring match on the normalized heading. of course, that assumes the subfields are in the desired order in the record. |
| 12:12 |
|
remingtron joined #evergreen |
| 12:13 |
miker |
berick: that's exactly what the human interface does |
| 12:13 |
miker |
there's an API for it and everything :) |
| 12:15 |
berick |
miker: oh, neat. well that's good to know. |
| 12:16 |
miker |
supercat does it, IIRC |
| 12:26 |
dans-datalogics |
phasefx: grepping for "ERR" has a lot of output. |
| 12:26 |
dans-datalogics |
Session Error: router private.localhost/open-ils.supercat IS NOT CONNECTED TO THE NETWORK!!! |
| 12:26 |
dans-datalogics |
XMPPReader.pm:234 Jabber Exception: Disconnected from Jabber server |
| 12:27 |
dans-datalogics |
lots of that |
| 12:27 |
phasefx |
dans-datalogics: so sounds like there may be something misconfigured, though you said it used to work? |
| 12:29 |
dans-datalogics |
phasefx: i would've sworn so, yeah. but at this point i'm thinking it might be better to start over than to try to find the one piece (or multiple pieces) that's wrong. |
| 12:30 |
dans-datalogics |
fortunately, this is just exploratory right now. we won't lose anything other than time if we start fresh. |
| 12:30 |
|
jihpringle joined #evergreen |
| 12:30 |
phasefx |
dans-datalogics: roger that |
| 12:31 |
berick |
gmcharlt: websockets + nginx -- did you encounter roadblocks there or was it more a case of missing tuits? |
| 12:32 |
gmcharlt |
berick: tuits - will be working on it next week as part of 2.5.0-beta, but certainly wouldn't mind if you want to try your hand at it |
| 12:32 |
berick |
Perry Mason and The Case of the Missing Tuits |
| 12:32 |
phasefx |
dans-datalogics: there are scripts that will install an EG test instance on, for example, Debian Wheezy, without all the manual steps |
| 12:32 |
berick |
gmcharlt: ok, good to know, thanks |
| 12:34 |
berick |
may have time to help on that soon |
| 12:39 |
dans-datalogics |
phasefx: i must've missed those. do they install opensrf as well? |
| 12:40 |
dans-datalogics |
or the other components? |
| 12:49 |
|
bmills joined #evergreen |
| 12:51 |
|
bmills1 joined #evergreen |
| 12:52 |
|
bmills1 joined #evergreen |
| 12:58 |
phasefx |
dans-datalogics: yeap, it does the whole kit and kaboodle. It's not part of EG proper, so don't be surprised you didn't see it. This is the one I'm familiar with: http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=README;h=c399f570ab4f0cfad83a01414b38b3b4bc82fa09;hb=refs/heads/collab/phasefx/wheezy_installer berick also updated it for Ubuntu, and is probably invoked similarly: |
| 12:59 |
phasefx |
http://git.evergreen-ils.org/?p=working/random.git;a=tree;h=refs/heads/collab/berick/ubuntu-auto-installer;hb=refs/heads/collab/berick/ubuntu-auto-installer |
| 13:00 |
dans-datalogics |
awesome, we'll give that a try! |
| 13:34 |
|
miker joined #evergreen |
| 13:34 |
|
graced joined #evergreen |
| 13:34 |
|
Shae joined #evergreen |
| 13:36 |
|
akilsdonk joined #evergreen |
| 13:36 |
|
jyorio joined #evergreen |
| 13:39 |
|
rhamby joined #evergreen |
| 13:40 |
|
abneiman joined #evergreen |
| 13:51 |
|
ssieb joined #evergreen |
| 14:08 |
|
cgreen joined #evergreen |
| 14:19 |
|
bmills joined #evergreen |
| 14:31 |
Stompro |
miker++, thanks for the notice. I was just on the phone with a branch who was saying "Random customers are getting host not found errors..." |
| 14:32 |
miker |
Stompro: np, wish we could do more :( |
| 14:42 |
csharp |
shared in #code4lib: https://twitter.com/sadserver/status/789524516582125568 |
| 14:44 |
* tsbere |
just ensures that all of the things his systems need from DNS are in a local DNS server to keep things more central ;) |
| 14:45 |
berick |
the irony of not being able to load twitter.com |
| 14:47 |
csharp |
berick: "your decision to manage /etc/hosts manually has finally paid off #thoughtleadership" |
| 14:48 |
* berick |
looks for an /etc/hosts dump of the entire internet |
| 14:48 |
csharp |
haha |
| 14:49 |
* jeff |
eyes some old optical media binders |
| 15:01 |
gsams |
odd question, is there any reason why a search facet wouldn't exactly match what it is referencing? example: Author facet shows "Patterson, James 1947-" actual entry is "Patterson, James, 1947-" |
| 15:02 |
gsams |
It's obviously a nitpick, but I have been asked and didn't see anything that would account for the second comma being missing. |
| 15:02 |
tsbere |
gsams: I assume that punctuation is generally going to be ignored and may come from whichever entry created the first DB entry or something |
| 15:03 |
* tsbere |
hasn't actually looked into how those work |
| 15:04 |
gsams |
tsbere: The oddity for me is that there is a facet that is the correct version, but it references records that haven't yet been attached to the Authority record. |
| 15:05 |
tsbere |
gsams: I don't think facets need the authority record linking to function |
| 15:06 |
gsams |
those records all have the data in the $a field, whereas the authority has "Patterson, James," in $a and "1947-" in $d |
| 15:07 |
gsams |
right, it should function regardless of authorities, but I wasn't sure if for some reason the facets strip out characters if the entry is split between subfields. |
| 15:07 |
tsbere |
Then what you are seeing may be "trim leading/trailing punctuation off of $a before $d is appended to it" or something? |
| 15:08 |
gsams |
tsbere: It must be, unless someone else suggests otherwise, I think this will be the answer that I give. |
| 15:09 |
gsams |
tsbere++ #thanks |
| 15:19 |
|
kmlussier joined #evergreen |
| 15:23 |
|
collum joined #evergreen |
| 15:27 |
Stompro |
click2mail-- |
| 16:13 |
Bmagic |
urrgg registry.npmjs.org down? |
| 16:13 |
tsbere |
may just be part of the ongoing issues |
| 16:24 |
* jeff |
nods |
| 16:24 |
jeff |
npmjs.org uses exclusively dynext.net nameservers. |
| 16:28 |
Bmagic |
I see |
| 16:47 |
berick |
cross-DST circs created between 0 and 1am getting wrong due date... sounds so familiar, but not seeing a LP for the specifically. |
| 16:48 |
tsbere |
around midnight opac renewals, I guess? |
| 16:49 |
berick |
problem seems to be that now + 'X days' is not the same as now + 'seconds-in-X-days seconds' when crossing the DST boundary |
| 16:49 |
berick |
tsbere: yeah |
| 16:53 |
tsbere |
berick: I find that to be fairly common in pretty much all date math situations |
| 17:04 |
berick |
maybe we could shove the interval math into the DB so we don't have to use interval_to_seconds. |
| 17:14 |
miker |
or use seconds_to_interval where appropriate? |
| 17:21 |
berick |
miker: not sure I follow. we have an interval from the circ duration. |
| 17:23 |
berick |
to recap: now() + '28 days'::interval is not the same as now() + '2419200 seconds'::interval when now() is within 28 days of the DST boundary. |
| 17:23 |
* berick |
opens an LP |
| 17:23 |
miker |
berick: I see what you mean |
| 17:23 |
miker |
and yep, they're not |
| 17:25 |
miker |
I wonder if we just need to look at the date::time api. see if there's a way to do the same thing with as little code change as possible |
| 17:26 |
miker |
datetime... no :s |
| 17:26 |
berick |
miker: agreed. was just poking around there |
| 17:26 |
|
bmills joined #evergreen |
| 17:28 |
miker |
(my worry is the possibility of moving everything to the db. not because that's bad, but because the current code is so heavily tested) |
| 17:30 |
berick |
yeah, i'm right there with you |
| 17:33 |
miker |
or, just tell patrons that, yeah, you lose a day in the fall but you get it back in the spring! ;) |
| 17:33 |
|
finnx left #evergreen |
| 17:34 |
berick |
hah |
| 17:40 |
berick |
easily reproduced in DateTime. ->add(days => ...) understands DST boundaries, ->add(seconds => ...) as expected does not. |
| 17:41 |
berick |
or rather is not affected by DST |
| 17:42 |
berick |
so maybe an interval_to_components function, that breaks it down into months/days/etc that we can be passwed to ->add(...) |
| 17:45 |
berick |
which brings us back to seconds_to_interval.. :) so, maybe a version of that which returns a hash (month =>.., days => ..., etc.) instead of a string. |
| 17:45 |
berick |
heh, or just get the string and split it |
| 17:45 |
berick |
miker++ # i'm getting there |
| 17:50 |
miker |
berick: could we just split and reverse? |
| 17:51 |
berick |
miker: yeah, splitting is where I ended up (2 lines up) :) |
| 17:52 |
miker |
the reverse would order the parts as we need them. stash in a hash if the api requires a hashref |
| 17:53 |
berick |
yeah, api wants a hash |
| 17:57 |
miker |
berick++ |
| 18:07 |
|
finnx joined #evergreen |
| 19:06 |
|
graced joined #evergreen |
| 19:06 |
|
Shae joined #evergreen |
| 19:06 |
|
dbwells joined #evergreen |
| 19:06 |
|
remingtron joined #evergreen |
| 19:06 |
|
Stompro joined #evergreen |
| 19:06 |
|
tsbere joined #evergreen |
| 19:07 |
|
sandbergja joined #evergreen |
| 19:07 |
|
Callender joined #evergreen |
| 19:07 |
|
Bmagic joined #evergreen |
| 19:07 |
|
jeff joined #evergreen |
| 19:07 |
|
berick joined #evergreen |
| 19:07 |
|
book` joined #evergreen |
| 19:07 |
|
miker joined #evergreen |
| 19:07 |
|
ssieb joined #evergreen |
| 19:07 |
|
jyorio joined #evergreen |
| 19:07 |
|
jihpringle joined #evergreen |
| 19:07 |
|
phasefx joined #evergreen |
| 19:08 |
|
Christineb joined #evergreen |
| 19:08 |
|
dcook joined #evergreen |
| 19:08 |
|
csharp joined #evergreen |
| 19:08 |
|
abneiman joined #evergreen |
| 19:08 |
|
rhamby joined #evergreen |
| 19:08 |
|
gsams joined #evergreen |
| 19:08 |
|
ejk joined #evergreen |
| 19:08 |
|
sard joined #evergreen |
| 19:13 |
|
bmills joined #evergreen |
| 19:28 |
|
wsmoak joined #evergreen |
| 19:48 |
jeffdavis |
wait, did you guys decide that you need to put the string down, split it and reverse it? |
| 20:56 |
|
dbs joined #evergreen |
| 21:02 |
|
ssieb joined #evergreen |
