| Time |
Nick |
Message |
| 03:09 |
|
Rogan joined #evergreen |
| 04:09 |
|
sleary joined #evergreen |
| 07:16 |
|
kworstell-isl joined #evergreen |
| 08:02 |
|
BDorsey joined #evergreen |
| 08:16 |
|
kworstell-isl joined #evergreen |
| 08:20 |
|
sleary joined #evergreen |
| 08:26 |
|
kworstell_isl joined #evergreen |
| 08:43 |
|
rfrasur joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 08:48 |
|
sandbergja joined #evergreen |
| 08:56 |
|
dguarrac joined #evergreen |
| 09:01 |
|
Dyrcona joined #evergreen |
| 09:13 |
Dyrcona |
Huh... It took about 8 hours to get through 27,500 autorenew events in my test last night. The test environment is configured like production, except I bumped the parallel settings for events up to 6 from 3. |
| 09:14 |
Bmagic |
autorenew is slow |
| 09:14 |
Dyrcona |
Some events got stuck. |
| 09:14 |
Dyrcona |
Yeah, I know. I think it could be faster if it wasn't done via action trigger. There'd be less overhead. |
| 09:15 |
Dyrcona |
I'm going to check the logs for 'no children' and 'backlog' messages. I think the parallel settings may have been too high for the rest of the configuration. |
| 09:18 |
Dyrcona |
Sep 19 08:01:43 jasontest open-ils.trigger: [WARN:59744:Server.pm:200:] server: no children available, waiting... consider increasing max_children for this application higher than 15 in the OpenSRF configuration if this message occurs frequently |
| 09:18 |
Dyrcona |
That's not right. I swear it is set to 40. |
| 09:18 |
* Dyrcona |
checks by asking opensrf.settings |
| 09:19 |
|
mantis1 joined #evergreen |
| 09:20 |
Dyrcona |
Ugh. I'm going to have to look up the correct call. It's gone from the srfsh history because I rebuilt the vm.... |
| 09:22 |
Dyrcona |
Yeah.. opensrf.settings.host_config.get shows max_children: 40 for open-ils.trigger..... |
| 09:23 |
Dyrcona |
osrf_control -l --diagnostic shows 10/40 currently running. |
| 09:24 |
Dyrcona |
Oh, that message is from 3 days ago! Duh! |
| 09:24 |
Dyrcona |
Guess syslog hasn't rotated. |
| 09:25 |
mantis1 |
this isn't EG specific but does anyone have experience with Marc Edit? |
| 09:25 |
Dyrcona |
I think I'd better look into that. syslog is 15GB and hasn't rotated for a few days. This was one of the symptoms that caused me to rebuild the vm last week. |
| 09:25 |
mantis1 |
trying to delete bibs in a .mrc if a local 852 doesn't have a libshortcode in it |
| 09:27 |
Dyrcona |
mantis1: I'd do that with Perl, but are you looking for records not having a 852$b or something like that? |
| 09:27 |
Dyrcona |
mantis1: You could try asking on the cataloging list. I'm sure someone there would know. |
| 09:30 |
mantis1 |
ok good call |
| 09:30 |
mantis1 |
Dyrcona++ |
| 09:30 |
Dyrcona |
Default directory permissions don't allow logrotate to run on Ubuntu 22.04. |
| 09:30 |
Dyrcona |
error: skipping "/var/log/messages" because parent directory has insecure permissions |
| 09:36 |
Dyrcona |
Whee! Ubuntu ships with broken config.... |
| 09:41 |
Dyrcona |
The configuration has also changed from 20.04.... It's rotating syslog weekly, not daily.... |
| 09:41 |
Dyrcona |
Think I'll change that. |
| 09:47 |
Dyrcona |
Maybe I should prepare a patch or a sed script to run when I setup new Ubuntu 22.04 vms? |
| 09:56 |
Dyrcona |
sed: Assembly language for text. :) |
| 09:58 |
Dyrcona |
It looks like Ubuntu 20.04 could benefit from a similar fix. logrotate emits a warning, but it's not a fatal error. |
| 09:58 |
|
sleary joined #evergreen |
| 10:07 |
Dyrcona |
I'm also wondering if my real issue was the change in schedule for sylsog rotation. It might have been rotating logs anyway.... Ah, well, I have it rotating daily again. |
| 10:12 |
Dyrcona |
Funny that I didn't notice that until now. |
| 10:14 |
Dyrcona |
Ooh. My change altered the group on the files when they're rotated.... I'll bet it was working, and my problem was the frequency.... |
| 10:55 |
Dyrcona |
Always something.... |
| 10:55 |
|
briank joined #evergreen |
| 10:58 |
Dyrcona |
Interesting. No /var/log/syslog on Debian Bookworm. I guess it's using systemd for logging by default. |
| 10:59 |
Dyrcona |
That's how it works on my Arch laptop. I access everything through journtalctl. |
| 11:00 |
Dyrcona |
I suppose that I could install rsyslog. |
| 11:28 |
|
sandbergja joined #evergreen |
| 11:30 |
|
jihpringle joined #evergreen |
| 11:36 |
|
sandbergja joined #evergreen |
| 12:27 |
|
jihpringle joined #evergreen |
| 12:32 |
|
sandbergja left #evergreen |
| 12:33 |
|
sandbergja joined #evergreen |
| 12:35 |
Dyrcona |
Interesting interplay with marc_export options, and I'm not sure it is always obvious.... |
| 12:35 |
Dyrcona |
It gets more complicated as we add new "features." |
| 12:51 |
Dyrcona |
marc_export needs better documentation anyway.... |
| 12:52 |
Dyrcona |
"We have a spreadsheet of just under 1,000 items that are lost. Can we delete these from the collection while keeping them on patrons' accounts?" |
| 12:53 |
Dyrcona |
Yes, but you'll be really confused when the item comes back and you try to check it in normally. |
| 13:02 |
rfrasur |
Uh...how long lost? |
| 13:02 |
|
JBoyer joined #evergreen |
| 13:02 |
rfrasur |
(and why delete rather than just filter out from report results or something?) |
| 13:03 |
rfrasur |
(why am I asking nonsensical things despite knowing they're nonsensical?) |
| 13:04 |
Dyrcona |
:) |
| 13:05 |
Dyrcona |
I don't know how long lost, but I wager several years. People do what people do.... |
| 13:06 |
rfrasur |
They do indeed do what they do. |
| 13:06 |
Dyrcona |
I built an interface to undelete items for XUL at MVLC because the members' tech. services staff were "delete happy" on lost and missing items. |
| 13:07 |
Dyrcona |
Well, it was just plain HTML, JavaScript, and Perl. It could be adapted to Angular, I suppose. Staff could upload a file of barcodes, and the latest deleted one would be undeleted if there wasn't a non-deleted copy with the same barcoce. |
| 13:08 |
Dyrcona |
I remember one story. A copy had been missing for "years" but they found it behind a radiator while cleaning before doing a renovation. |
| 13:08 |
Dyrcona |
Anyway...... |
| 13:08 |
rfrasur |
We have two library systems that are VERY notorious for needing to have items undeleted. Not sure what's going on in their systems, but dang. And it's noticeable because it's just the two of them. |
| 13:08 |
Dyrcona |
Yeah, I'd say it was one or two at MVLC that did this the most. |
| 13:09 |
rfrasur |
But...they're doing work and the libraries "work." So...whatevs. It's cool. |
| 13:09 |
Dyrcona |
:) |
| 13:10 |
|
jihpringle joined #evergreen |
| 13:12 |
Dyrcona |
I've become very relaxed about these things lately. I'm like, "OK. Here's the rope. Have fun!" |
| 13:13 |
rfrasur |
Same. Or..."the rope is an illusion" even. We do what we do until we can't. Things work until they don't. If we want them to keep working a little longer, we put in a little more work to maintain. If we're alone in that, there is no community and it's already broken. In the meantime...here we are. |
| 13:14 |
Dyrcona |
Yes, exactly that. |
| 13:14 |
Dyrcona |
Though I'd say the rope is an allusion. |
| 13:14 |
Dyrcona |
:P |
| 13:14 |
rfrasur |
lol, an illusion AND an allusion. |
| 13:15 |
Dyrcona |
Related, but not exactly, I wonder if a line of code in the marc_export feature branch to exclude bibs with non-opac visible copies is doing what it is supposed to do. Negative logic (i.e. not ....) can be difficult to think about. |
| 13:16 |
Dyrcona |
An allusion to an illusion... |
| 13:17 |
rfrasur |
hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm |
| 13:17 |
rfrasur |
Well, i dunno if it's doing what it's supposed to do or not...but hopefully it is. |
| 13:18 |
Dyrcona |
Well, it's doing what it "says" it's doing... If --items and --excude-hidden and --uris are all passed, then records without visible items are being exported if they have URIs. |
| 13:19 |
Dyrcona |
If --uris is not included, then records with URIs are not exported. |
| 13:19 |
Dyrcona |
It gets interesting when you add in options to limit to certain libraries' collections. |
| 13:19 |
rfrasur |
Would you expect it to do something besides what it says it's doing? Ohhhh, that would make it interesting. |
| 13:20 |
rfrasur |
Very |
| 13:20 |
rfrasur |
Gross. |
| 13:20 |
Dyrcona |
Well, I think --items by itself skips records with URIs, so I guess the behavior with that option is to be expected. |
| 13:21 |
Dyrcona |
Adding in a location without --items or --uris exports all records for that location with records or URIs because the check is only made against the call number table. |
| 13:22 |
Dyrcona |
Originally, as implemented by gmcharl and modified by Stompro, --exclude-hidden did nothing unless --items was used, but I'm playing with making it do something even if item info isn't exported. |
| 13:23 |
rfrasur |
that still scopes to a library's collections but doesn't export the holding info? |
| 13:23 |
Dyrcona |
So, right now, --exclude-hidden with a location excludes records with non-opac visible copies and those with URIs. Adding --uris will include records with URIs. |
| 13:23 |
Dyrcona |
Right. |
| 13:23 |
rfrasur |
That could be mighty useful. |
| 13:24 |
Dyrcona |
It is mighty useful, but we usually use it in conjunction with --items to get item information. |
| 13:25 |
rfrasur |
Right, but it could be useful to not include that item information too. |
| 13:25 |
Dyrcona |
Yeah. |
| 13:25 |
Dyrcona |
You can also export just records with URIs if you pass a location and --uris. It skips those with items. |
| 13:27 |
Dyrcona |
Adding --exclude-hidden to that combination includes records that have opac visible items, but doesn't export item information. |
| 13:27 |
Dyrcona |
I suppose it all makes sense.... |
| 13:28 |
JBoyer |
Dyrcona, it occurs to me since I know what you're looking at that I should probably say the way we extract things we always feed marc_export a list of specific ids, we never just let it do its thing directly via cmdline options. |
| 13:28 |
Dyrcona |
I may want to edit the release note. Some examples might be useful. |
| 13:28 |
Dyrcona |
JBoyer: I often do the same. |
| 13:29 |
Dyrcona |
But that is a good point. I should make sure that these options don't interfere with --pipe, or should it? |
| 13:29 |
JBoyer |
+1, just didn't want you chasing waterfalls in case you were trying to find just the right combinations of params for an Aspen extract. |
| 13:31 |
JBoyer |
and I don't think any recent patches should touch the "acquire a list of ids" part, so --pipe should work as expected everywhere. |
| 13:31 |
Dyrcona |
JBoyer: Oh no, it wasn't that. I was just experimenting with --exclude-hidden and looking at what happens when it is expanded to work without the --items option. I think I'm satisfied with that at this point. I'll let someone else look at it before it goes to main, though. |
| 13:31 |
JBoyer |
Dyrcona++ |
| 13:32 |
Dyrcona |
I'll have another look at the code and do an export with --pipe to see what happens. |
| 13:32 |
Dyrcona |
JBoyer++ rfrasur++ |
| 13:33 |
Dyrcona |
Some of this behavior I described has been there for a while now. I only just really understood it today. |
| 13:33 |
rfrasur |
Dyrcona++ |
| 13:43 |
|
rfrasur joined #evergreen |
| 13:43 |
|
rfrasur left #evergreen |
| 13:46 |
Dyrcona |
Looks like the options that will limit the output do have an affect with --pipe. The list of bib ids is added to the main query with an IN clause, so if there's a bib in that list with no opac visible copies it would be skipped with --exclude-hidden. I think that's to be expected. |
| 13:49 |
Dyrcona |
Once you get beyond 2 or 3 simple options, behavior of a program can appear nondeterministic. |
| 13:52 |
|
redavis_ joined #evergreen |
| 13:53 |
|
redavis joined #evergreen |
| 14:13 |
jeffdavis |
JBoyer++ # TLC reference |
| 14:15 |
JBoyer |
;) |
| 14:21 |
redavis |
Going through 2021 community survey results and trying to resist the urge to respond to 50% of the comments with "DONE" or "IN PROCESS" or "YOU ARE THEM." |
| 14:21 |
redavis |
Old data is frustrating data. |
| 14:22 |
redavis |
also, rfrasur is old data. redavis is new data. |
| 14:30 |
JBoyer |
redavis++ meant to say congrats sooner |
| 14:31 |
redavis |
Psh, thanks and also no need. I just didn't want to go around confusing people thinking we had a new community member or something. (ahahahahahah...sorry) |
| 14:32 |
redavis |
Also, JBoyer++ # you are kind |
| 14:36 |
|
sleary joined #evergreen |
| 14:38 |
|
jonadab joined #evergreen |
| 14:54 |
redavis |
oh ho! The tropical storm about "hit" eastern VA just got a name! Ophelia. Noice. |
| 14:56 |
|
sleary joined #evergreen |
| 15:30 |
|
mantis1 left #evergreen |
| 16:59 |
|
mmorgan left #evergreen |
| 17:27 |
|
sleary joined #evergreen |
