Evergreen ILS Website

IRC log for #evergreen, 2019-05-28

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:24 JasonEDN1 joined #evergreen
00:28 JasonEDN joined #evergreen
04:32 jamesrf joined #evergreen
05:31 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:48 JBoyer joined #evergreen
06:50 agoben joined #evergreen
07:52 rjackson_isl joined #evergreen
07:54 jamesrf joined #evergreen
08:13 bos20k joined #evergreen
08:15 collum joined #evergreen
08:38 rjackson_isl joined #evergreen
08:43 mmorgan joined #evergreen
08:50 rjackson_isl joined #evergreen
08:53 rjackson_isl joined #evergreen
09:10 yboston joined #evergreen
09:24 tlittle joined #evergreen
09:25 sandbergja joined #evergreen
09:43 Christineb joined #evergreen
09:47 Dyrcona joined #evergreen
09:52 csharp closely monitoring the logs this morning as the day after Memorial Day is our busiest historically...
09:53 csharp I'd love to see some defensive coding around the Apache2::RequestIO::print: (32) Broken pipe errors and am interested in helping accomplish that
09:59 Dyrcona csharp: Not sure what you can do about that. I believe the majority come from the client going away/reloading the page before the output is complete.
10:01 Dyrcona I checked for errors on Sunday because that's our busiest day on Monday holiday long weekend because of all the 2-day courtesy notices.
10:01 Bmagic If you leave the console tty session open after you start websocketd & - do you also see the same ERROR messages that I see? "Unexpected error while reading STDERR from process: read IO: file already closed"
10:01 csharp I've not tried that
10:01 Dyrcona But, we had a problem this morning with the pending a/t runner from a large purchase order.
10:01 Dyrcona Bmagic: Yes, I do.
10:02 Dyrcona You can ignore them.
10:02 Bmagic sorry - unrelated to Apache2::RequestIO::print
10:02 Bmagic Ok great! I was hoping that was the answer
10:02 csharp Bmagic: no prob :-)
10:02 Dyrcona Bmagic: Add this: >& /dev/null before your last &
10:03 Bmagic right, I was considering that
10:03 Dyrcona /usr/local/bin/websocketd [arguments] >& /dev/null &
10:03 Bmagic TY
10:03 Dyrcona I use sudo -b instead of the last & to put it in the background.
10:04 Dyrcona Doesn't make much difference, but I sudo it to root for reasons.
10:04 Bmagic I found out the hard way that running it as root fools you into thinking it will work but it seems to die after a day or so
10:04 Dyrcona Bmagic: websocketd has never died for me.
10:04 csharp we've seen it die, but it's rare so far
10:05 Bmagic well, I don't know why but this morning it wasn't running. I assumed it was because it was started as root
10:05 csharp set up monitoring for it, though so we can catch it quickly
10:05 khaun joined #evergreen
10:05 Dyrcona Bmagic: What version? There was an update posted that's newer than the version in the README.
10:06 Bmagic websocketd-0.3.0-linux_amd64.zip
10:06 Bmagic so, I guess that might have something to do with it
10:07 csharp command[check_websocketd]=/usr/​lib/nagios/plugins/check_procs -c 1:1 -C websocketd in /etc/nagios/nrpe_local.cfg on the remote box, then configure nagios/icinga to run that command (for the logs)
10:08 Dyrcona Bmagic: I believe I'm using 0.3.1, but I'd have to check the server to make certain.
10:08 Dyrcona May be 0.3.2, but not sure if that even exists.
10:09 Dyrcona I can check in a moment. I want to close the ticket that I opened about the PO that crashed this morning. I just verified that the message was created.
10:11 Dyrcona websocketd-0.3.1-linux_amd64.zip
10:11 tlittle joined #evergreen
10:12 nfBurton joined #evergreen
10:13 csharp 0.3.1 is still marked "pre-release" in github
10:13 csharp "Go was significantly upgraded since 1.9 so it's time to re-build.
10:13 csharp Besides that websocketd did not change."
10:14 Dyrcona IDK. I'm using it, and I've never had websocketd crash, yet.
10:15 Dyrcona The zip file is 1.2 MB bigger, so something changed.
10:16 Dyrcona I haven't compared the actual websocketd binaries.
10:19 Bmagic interesting
10:24 jamesrf joined #evergreen
10:36 yar joined #evergreen
10:37 khuckins joined #evergreen
10:40 Dyrcona Bmagic: I was just looking at Lp 1532236 because someone asked me if we could bold something in an email notice. Do you think that code is ready for a "pullrequest" tag? And, are you using it in production?
10:40 pinesol Launchpad bug 1532236 in Evergreen "Evergreen should allow for HTML formatted action trigger emails" [Wishlist,Confirmed] https://launchpad.net/bugs/1532236
11:02 miker csharp / Bmagic: both of your error messages are about the client quiting before the response is sent, I'm 99% sure.  for the apache version of that, there are patches for both opensrf and evergreen (probably still untested) to detect the situation and cancel ongoing requests (think: 100 refreshes of a search, and cutting the first 99 off because they're now just wasting server time). we can't really detect the websockets version, though -- it just
11:02 miker runs our code as an external command and shovels the bits between our stdout and a socket.
11:18 csharp miker: thanks for that - do you know the bug #s for the patches?
11:18 * miker looks...
11:20 miker csharp: heh ... you were the last to test the evergreen part, actually: https://bugs.launchpad.net/opensrf/+bug/1616501 ... and the opensrf part is in there now, as it turns out
11:20 pinesol Launchpad bug 1616501 in Evergreen "Stop waiting for method response when browser disconnects" [Medium,Confirmed]
11:29 Bmagic Dyrcona: we have it running in production. Yes I believe it's good for a pullrequest. If people had tried to setup HTML templates and they weren't working, then left them alone, with this patch, they will suddenly start working. RE: comment #3
11:30 Dyrcona We might be interested in having a look.
11:42 jamesrf joined #evergreen
11:56 csharp miker: figures - my memory is like a seive nowdays :-)
12:10 yboston joined #evergreen
12:12 sandbergja joined #evergreen
13:06 sandbergja_ joined #evergreen
13:12 jamesrf joined #evergreen
13:49 littlet joined #evergreen
14:21 khuckins joined #evergreen
14:45 csharp a19bf249
14:45 pinesol csharp: [evergreen|Thomas Berezansky] LP#1413624: OpenILS::WWW::AccessHandler Module - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=a19bf24>
14:49 * Dyrcona wonders why csharp put that in the channel.
14:50 csharp Dyrcona: I was trying to figure out why I was getting conflicts when cherry-picking miker's branch to fix bug 1616501 - answer: I missed a commit :-)
14:50 pinesol Launchpad bug 1616501 in Evergreen "Stop waiting for method response when browser disconnects" [Medium,Confirmed] https://launchpad.net/bugs/1616501
14:51 Dyrcona OK, then. :)
14:51 Dyrcona Debuggin via IRC.... :)
14:51 csharp guess I could've done git show instead :-)
14:52 Dyrcona That's a lesser known feature of Evergreen, and I sometimes think people recreate it unnecessarily when I hear about authentication schemes that they've come up with.
14:56 sandbergja_ joined #evergreen
15:36 jeff under 3.1, selecting two items (on two different records) in item status and then selecting Actions -> Show Record Holds generally results in a hung progress bar on one or both new tabs. There's also some weirdness with the record summary data not drawing. Reload doesn't seem to fix it, but hard reload may.
15:37 jeff I can't reproduce on a newer system, so I'm hoping it's a fixed bug but I'm not able to find a matching bug in lauchpad. Just some potential candidates.
15:44 mmorgan When upgrading from 3.1 to 3.2 - has anyone had issues with the workstation settings moving from the the browser to the database? Or is it seamless?
15:45 csharp mmorgan: we went from 3.0 to 3.2 without noticeable problems
15:45 jeff ah, and it's calling open-ils.circ.holds.retrieve_all_from_title for record null
15:46 mmorgan csharp: Thanks, that's good to know!
15:46 csharp mmorgan: possible complications may arise with Hatch vs. non-Hatch storage, though
15:46 csharp but that's always been true
15:49 mmorgan Do settings need to be stored in Hatch to migrate to the database?
15:50 berick mmorgan: no, the migration will handle localStorage settings too
15:50 mmorgan Ok, that's good.
15:57 jeff Found the (handy!) devtools setting for opening devtools on new popups... and I can't reproduce the problem with devtools open.
15:57 berick yeah, still no setting for that
16:00 jeff but it does look like it might be related to bug 1705286...
16:00 pinesol Launchpad bug 1705286 in Evergreen "webstaff: grid fetch for View Holds grid can be called twice in quick succession" [Medium,New] https://launchpad.net/bugs/1705286
16:00 jeff i need to dig further.
16:13 mmorgan1 joined #evergreen
16:18 yboston joined #evergreen
16:39 Dyrcona csharp: Going back to last week's conversation about open-ils.actor drone usage, it seem pretty uneven to me. I see one of two drones at 20% and the other close to 90%. On another brick, they're both over 75%.
16:49 jamesrf joined #evergreen
16:52 Dyrcona Hmm... It looks a little more even, now, at from pairs of drone server. Still some bricks at 70% or so, and others at 17-20%.
16:54 Dyrcona Really? "no_tz.open-ils.storage.actor.user.crazy_search"
16:58 mmorgan joined #evergreen
17:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
17:16 mmorgan left #evergreen
17:50 berick love there's an EDI code for "number of law suits"
18:18 Dyrcona @quote add <berick> love there's an EDI code for "number of law suits"
18:18 pinesol Dyrcona: The operation succeeded.  Quote #199 added.
18:21 Dyrcona @quote random
18:21 pinesol Dyrcona: Quote #185: "terran: If this is Tuesday, the last six weeks have all been Mondays." (added by Dyrcona at 02:34 PM, March 06, 2018)
18:21 Dyrcona True data.
18:21 Dyrcona heh....
18:28 gsams joined #evergreen
21:27 jamesrf joined #evergreen
22:14 jamesrf joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat