Re: [OPEN-ILS-GENERAL] Overdue Fines Issue

[JonGeorg SageLibrary]

I had gotten that format from one of our internal documents, and it didn't
work with or without sudo, or as opensrf or root. Running /openils/bin/
fine_generator.pl /openils/conf/opensrf_core.xml as opensrf did work
correctly. Thank you for pointing that out - I updated the documentation,
and of course that makes sense because that matches what the crontab listed
which I feel silly for not checking earlier.

When I pull up action.circulation.stop_fines and stop_fines_time I get
nothing for that item.
-Jon

On Mon, Apr 1, 2019 at 5:16 PM Jason Stephenson  wrote:

>
>
> On 4/1/19 7:51 PM, JonGeorg SageLibrary wrote:
> > When I look at syslog it shows the fine generator runs at :05 and :40
> > every hour.
> >
> > My understanding was that the lock file was only present when it was
> > actively running. I tested that today at 16:40 and it was present for
> > about 90 seconds or so before deleting itself.
>
> Mine runs for nearly an hour, but yeah.
>
> >
> > As far as attempting to run the command sudo
> > /openils/bin/fine_generator.pl  as root, I get
> > the response bootstrap config required. However, that is the same
> > response I had gotten after a restart of the server in the past when it
> > was working properly. And when I tried to research that response, I
> > couldn't find anything useful in the forums, and since it was working
> > correctly as a cronjob I didn't pursue it.
>
> /openils/bin/fine_generator.pl /openils/conf/opensrf_cor.xml
>
> That command line should work as the opensrf user. You don't need, nor
> want, to use sudo when running these commands as the opensrf user.
>
> Have you checked the stop_fines field on the circulations that are not
> calculating fines?
>
>
>
> >
> > -Jon
> >
> > On Mon, Apr 1, 2019 at 3:39 PM Jason Stephenson  > > wrote:
> >
> > On 4/1/19 4:50 PM, JonGeorg SageLibrary wrote:
> > > No, there is no /tmp/generate_fines-LOCK file.
> > >
> > > Yes, I get a PID when running sudo pgrep -af fine
> >
> > You should get more than a PID.  It should include the command line
> that
> > started the fine generator, unless your pgrep doesn't process one of
> the
> > options correctly.
> >
> > Also, if the fine generator is running, the lock file should exist.
> If
> > it doesn't, then something is wrong.  However, I've never seen that
> > case, so I don't know what is wrong.
> >
> > What happens if you run the fine generator from the command line?
> >
> > Jason
> >
>

Re: [OPEN-ILS-GENERAL] Overdue Fines Issue

[Jason Stephenson]

On 4/1/19 7:51 PM, JonGeorg SageLibrary wrote:
> When I look at syslog it shows the fine generator runs at :05 and :40
> every hour. 
> 
> My understanding was that the lock file was only present when it was
> actively running. I tested that today at 16:40 and it was present for
> about 90 seconds or so before deleting itself.

Mine runs for nearly an hour, but yeah.

> 
> As far as attempting to run the command sudo
> /openils/bin/fine_generator.pl  as root, I get
> the response bootstrap config required. However, that is the same
> response I had gotten after a restart of the server in the past when it
> was working properly. And when I tried to research that response, I
> couldn't find anything useful in the forums, and since it was working
> correctly as a cronjob I didn't pursue it.

/openils/bin/fine_generator.pl /openils/conf/opensrf_cor.xml

That command line should work as the opensrf user. You don't need, nor
want, to use sudo when running these commands as the opensrf user.

Have you checked the stop_fines field on the circulations that are not
calculating fines?



> 
> -Jon
> 
> On Mon, Apr 1, 2019 at 3:39 PM Jason Stephenson  > wrote:
> 
> On 4/1/19 4:50 PM, JonGeorg SageLibrary wrote:
> > No, there is no /tmp/generate_fines-LOCK file. 
> >
> > Yes, I get a PID when running sudo pgrep -af fine
> 
> You should get more than a PID.  It should include the command line that
> started the fine generator, unless your pgrep doesn't process one of the
> options correctly.
> 
> Also, if the fine generator is running, the lock file should exist.  If
> it doesn't, then something is wrong.  However, I've never seen that
> case, so I don't know what is wrong.
> 
> What happens if you run the fine generator from the command line?
> 
> Jason
> 

Re: [OPEN-ILS-GENERAL] Overdue Fines Issue

[JonGeorg SageLibrary]

When I look at syslog it shows the fine generator runs at :05 and :40 every
hour.

My understanding was that the lock file was only present when it was
actively running. I tested that today at 16:40 and it was present for about
90 seconds or so before deleting itself.

As far as attempting to run the command sudo /openils/bin/fine_generator.pl
as root, I get the response bootstrap config required. However, that is the
same response I had gotten after a restart of the server in the past when
it was working properly. And when I tried to research that response, I
couldn't find anything useful in the forums, and since it was working
correctly as a cronjob I didn't pursue it.

-Jon

On Mon, Apr 1, 2019 at 3:39 PM Jason Stephenson  wrote:

> On 4/1/19 4:50 PM, JonGeorg SageLibrary wrote:
> > No, there is no /tmp/generate_fines-LOCK file.
> >
> > Yes, I get a PID when running sudo pgrep -af fine
>
> You should get more than a PID.  It should include the command line that
> started the fine generator, unless your pgrep doesn't process one of the
> options correctly.
>
> Also, if the fine generator is running, the lock file should exist.  If
> it doesn't, then something is wrong.  However, I've never seen that
> case, so I don't know what is wrong.
>
> What happens if you run the fine generator from the command line?
>
> Jason
>

Re: [OPEN-ILS-GENERAL] Overdue Fines Issue

[JonGeorg SageLibrary]

No, there is no /tmp/generate_fines-LOCK file.

Yes, I get a PID when running sudo pgrep -af fine

-Jon



On Mon, Apr 1, 2019 at 1:28 PM Jason Stephenson  wrote:

> Is there a file called /tmp/generate_fines-LOCK?
>
> If so, is the fine generator actually running? You can find out with
> something like:
>
> pgrep -af fine
>
> You may have a lock file hanging around from a crash or from having
> stopped services while the fine generator was running.
>
>

Re: [OPEN-ILS-GENERAL] Overdue Fines Issue

[JonGeorg SageLibrary]

Yes, I verified that the value in action.circulation.recurring_fine is
greater than 0.

More information on the error:

Here is what I have so far --
---money.usr_summary.total_owed and * in money.billable_xact_summary -
matches the web and xul client data for the user.
---* in reporter.overdue_circs for the user shows the correct rules, fines,
etc in place
---Pulling everything by date from money.billing in separate reports for
several days in a row each show the rules applied to the items for this
patron as well as a host of others, so it gives the illusion that the fines
are being calculated daily. However there is no history table for item
charges that I could find, like there is for item status changes, etc. so I
cannot think of a way to pull a list showing individual charges per item
per day to verify they are being calculated per day and not when the status
change triggers it. Am I missing something - is there a way to pull that
data?

I've also tried looking in auditor.asset_copy_history as well as other
locations. All information I get back shows the same thing.

The items to this particular patron were due on 3/14/19, and were charged
for 9 days and then it appears to have stopped. Each item had not yet hit
the max fine rule, they stopped at 36% of it. The items have not yet been
returned, but in other instances of this issue, when the status of the item
changes the fees/fines are calculated and then presented to the patron --
which can come as a surprise to patrons and staff since if they had checked
their account before turning the items in, they could have a wildly
different amount due like in this case.

The dates this stopped displaying do not appear to correspond to the dates
I did server maintenance or restarted services.

When I look at the circ, recurring and max fine rules they all look normal
and correct as they haven't been changed in years. The recurrence interval
is set to 1 day. This particular patron does have some lost items on their
account as well, and when I checked we do not have things like 'max payment
allowed' configured under library settings so there shouldn't be an issue
with hitting something like a patron max cap if there is even such a thing,
and regardless that wouldn't explain the other patron accounts that are
doing the same thing that don't have large additional fees on their account.

To add to the confusion, I restarted the log server the night of the 28th
which hosts the fine_generator.pl script and since then an additional day's
fees have been added to the items checked out to that patron, but not for
every day since that restart - which leads me to believe it's potentially
the fine_generator not running correctly, and yet, why did it add one day
and not all the days that were missing? And why are there no errors in
syslog?

I checked the open bug reports and don't see anything matching what I'm
seeing in this case.

Is anyone else having this issue?
-Jon

On Thu, Mar 28, 2019 at 10:33 AM JonGeorg SageLibrary <
jongeorg.sagelibr...@gmail.com> wrote:

> I'm trying to isolate an issue with our overdue fines not working. It
> seems sporadic. There are no errors in the syslog, and the cron job is
> running every 25 minutes without errors. Some libraries are reporting the
> fines not accruing, but it seems hit and miss. I've restarted postgreSQL on
> the database server a couple of times in the past couple of weeks due to
> high CPU load, and did install Ubuntu 16.04 updates/security patches but
> none of that should have affected anything. I even reviewed the screen
> capture of the session where I installed updates and didn't see anything
> unusual. We are running Evergreen 3.1.7 although we're going to upgrade to
> 3.1.10 on the 10th.
>
> Does anyone have suggestions on additional things to check?
> -Jon
>

Re: [OPEN-ILS-GENERAL] Overdue Fines Issue

[Morgan, Michele]

Jon,

Have you confirmed that the circulation policies for the transactions in
question are set to accrue fines?

For the transactions in question the action.circulation.recurring_fine
field should have a value greater than zero. If it does not, check the
circulation policies.

Hope this helps,
Michele
--
Michele M. Morgan, Technical Support Analyst
North of Boston Library Exchange, Danvers Massachusetts
mmor...@noblenet.org



On Thu, Mar 28, 2019 at 1:34 PM JonGeorg SageLibrary <
jongeorg.sagelibr...@gmail.com> wrote:

> I'm trying to isolate an issue with our overdue fines not working. It
> seems sporadic. There are no errors in the syslog, and the cron job is
> running every 25 minutes without errors. Some libraries are reporting the
> fines not accruing, but it seems hit and miss. I've restarted postgreSQL on
> the database server a couple of times in the past couple of weeks due to
> high CPU load, and did install Ubuntu 16.04 updates/security patches but
> none of that should have affected anything. I even reviewed the screen
> capture of the session where I installed updates and didn't see anything
> unusual. We are running Evergreen 3.1.7 although we're going to upgrade to
> 3.1.10 on the 10th.
>
> Does anyone have suggestions on additional things to check?
> -Jon
>

[OPEN-ILS-GENERAL] Overdue Fines Issue

[JonGeorg SageLibrary]

I'm trying to isolate an issue with our overdue fines not working. It seems
sporadic. There are no errors in the syslog, and the cron job is running
every 25 minutes without errors. Some libraries are reporting the fines not
accruing, but it seems hit and miss. I've restarted postgreSQL on the
database server a couple of times in the past couple of weeks due to high
CPU load, and did install Ubuntu 16.04 updates/security patches but none of
that should have affected anything. I even reviewed the screen capture of
the session where I installed updates and didn't see anything unusual. We
are running Evergreen 3.1.7 although we're going to upgrade to 3.1.10 on
the 10th.

Does anyone have suggestions on additional things to check?
-Jon