(Forwarded from PttBug)「登入次數」的累計盲點 #104
Comments
|
實作登入次數自動增加機制的程式碼，根據以 PttBBS 原始碼為範圍、使用 ripgrep 所取得的字串搜尋結果，推測有兩處：
上述兩者在增加登入次數（ 節錄自
|
IepIweidieng
added a commit
to IepIweidieng/pttbbs
that referenced
this issue
Jun 3, 2021
Legend:
* Event: Name of event ("Login", "UpdateDN" (by update_online), and "Logout")
* UpdateDN: Update on day N (day 1 is the day of login)
* UpdateDN is assumed to usually occur at 04:00:00 each day
* If Login and UpdateD1 occur at the same time,
UpdateD1 is omitted from the chart for clarity
* Time: Time of event
* TDur: Total online duration since login
* CTime/NTime: Checkpoint (lastlogin) set by the current method/this new method
* CDurB/A: Online duration before/after the checkpoint is set (current method)
* NDurB/A: Online duration before/after the checkpoint is set (new method)
* CIncr/NIncr: Increment of numlogindays (current/new method)
---
Case: Online duration after last checkpoint = 1 day (86400 seconds)
The login count does not increase when the online duration = 1 day
due to a regression introduced in 05bb3eb,
where >= instead of > was used to filter out users
whose last checkpoint time (lastlogin) were later than 1 day before now.
Event: Login UpdateD2 UpdateD3 UpdateD4 UpdateD5
Time: 04:00:00 28:00:00 52:00:00 76:00:00 100:00:00
TDur: 00h00m00 24h00m00 48h00m00 72h00m00 96h00m00
CTime: 04:00:00 -- 52:00:00 -- 100:00:00
CDurB: 00h00m00 24h00m00 48h00m00 24h00m00 48h00m00
CDurA: 00h00m00 -- 00h00m00 -- 00h00m00
CIncr: +1 0 +1 0 +1 Total: +3
NTime: 04:00:00 28:00:00 52:00:00 76:00:00 100:00:00
NDurB: 00h00m00 24h00m00 24h00m00 24h00m00 24h00m00
NDurA: 00h00m00 00h00m00 00h00m00 00h00m00 00h00m00
NIncr: +1 +1 +1 +1 +1 Total: +5
This caused the login count to increases only by 1 per 2 days
for users who never logout.
This regression is fixed by using > for filter out users
to allow users with online duration = 1 day to have their login count increased.
For the rest cases, assume this regression is fixed for the current method.
---
Case: The launch of update_online by cron lagged or even failed
In this fictitious case,
the launch of update_online lags for 1 seconds on day 2 and fails on day 5.
Event: Login UpdateD2 UpdateD3 UpdateD4 UpdateD6
Time: 04:00:00 28:00:01 52:00:00 76:00:00 124:00:00
TDur: 00h00m00 24h00m01 48h00m00 72h00m00 120h00m00
CTime: 04:00:00 28:00:01 -- 76:00:00 124:00:00
CDurB: 00h00m00 24h00m01 23h59m59 47h59m59 48h00m00
CDurA: 00h00m00 00h00m00 -- 00h00m00 00h00m00
CIncr: +1 +1 0 +1 +1 Total: +4
NTime: 04:00:00 28:00:00 52:00:00 76:00:00 124:00:00
NDurB: 00h00m00 24h00m01 24h00m00 24h00m00 48h00m00
NDurA: 00h00m00 00h00m01 00h00m00 00h00m00 00h00m00
NIncr: +1 +1 +1 +1 +2 Total: +6
---
Case: Same total online duration, different login count increment
Compare the following cases.
Event: Login UpdateD2 UpdateD3 Logout
Time: 04:00:01 28:00:00 52:00:00 52:00:03
TDur: 00h00m00 23h59m59 47h59m59 48h00m02
CTime: 04:00:01 -- 52:00:00 --
CDurB: 00h00m00 23h59m59 47h59m59 00h00m03
CDurA: 00h00m00 -- 00h00m00 --
CIncr: +1 0 +1 0 Total: +2
NTime: 04:00:01 -- 28:00:01 52:00:03
NDurB: 00h00m00 23h59m59 47h59m59 24h00m02
NDurA: 00h00m00 00h00m00 23h59m59 00h00m02
NIncr: +1 0 +1 +1 Total: +3
Event: Login UpdateD1 UpdateD2 UpdateD3 Logout
Time: 03:59:59 04:00:00 28:00:00 52:00:00 52:00:01
TDur: 00h00m00 00h00m01 24h00m01 48h00m01 48h00m02
CTime: 03:59:59 -- 52:00:00 -- --
CDurB: 00h00m00 00h00m01 24h00m01 24h00m00 00h00m01
CDurA: 00h00m00 -- 00h00m00 00h00m00 --
CIncr: +1 0 +1 +1 0 Total: +3
NTime: 03:59:59 -- 27:59:59 51:59:59 --
NDurB: 00h00m00 00h00m01 24h00m01 24h00m01 00h00m02
NDurA: 00h00m00 -- 00h00m01 00h00m01 --
NIncr: +1 0 +1 +1 0 Total: +3
---
* mbbsd/passwd.c
* util/update_online.c
IepIweidieng
added a commit
to IepIweidieng/pttbbs
that referenced
this issue
Jun 15, 2021
The method for increasing user's login count has been refined
to prevent undercounting of the login times. It works as follows:
* Login time increment at login (the same as the current method)
For users who haven't logged in today, increase their login count by 1 at login.
* Login time increments according to the online duration
When either update_online runs *or the user logs out*,
if the user's online duration reaches N days (>= N⋅86400 seconds),
increase the user's login count by N and the user's lastlogin by N days.
(Increasing lastlogin by N days makes the online duration decrease by N days)
Compare it to the current method:
* The online duration is not checked at logout -> is checked at logout
* Increment is performed only when the online duration *exceeds* 1 day (> 86400 seconds).
-> is performed also when the duration reaches 1 day (= 86400 seconds)
* Explained below as the login count increment rate issue
* The login count only increases by 1 -> can increase by N
* lastlogin is set to the current time (resets the online duration to 0)
-> lastlogin is increased by N days (reduces the online duration by N days)
* A reset would cause users to lose some of their online duration,
enough to cause undercounting.
* The reset method is also prone to unpredictable cron job delays.
Executing update_online is no longer necessary to increase users' login count
but is still needed to minimize users' loss of login times
due to abnormal termination of their session.
---
The login count increment rate issue
resulted from the slightly flawed condition for excluding users from increment.
The condition should exclude users whose online duration < 1 day.
When update_online was introduced on 2014-03-25 (UTC+8),
this condition was wrongly flipped as `u->lastlogin + DAY_SECONDS <= now`.
It was corrected within an hour to be `now < urec.lastlogin + DAY_SECONDS`
(equivalently `urec.lastlogin + DAY_SECONDS > now`).
See commits 4f69140 ("Add utility to update user online counter (lastlogin/numlogindays).")
and 6871fbb ("Update using ulist.") for details.
A 1-hour tolerance of online duration was soon introduced and cancelled.
See commit 05702e5 ("update_online: prevent too verbose messages and allow some tolerance in duration.").
Within 1 day, another commit changed this condition to `urec.lastlogin >= base`,
where `base` was defined as 09:40 of the current day (in the local timezone).
It may have meant to increase the login count for users logged in before 09:40.
This was stated to be inspired by the login time increment at login.
However, update_online seems to have run at 00:00 of the day at that time.
This made the condition always false since 09:40 would be a time in the future,
and thus all online users' login count were increased unconditionally.
This caused overcounting of the login times, as users might manage to log in
at 00:00 and before update_online ran, thus getting 2 login times on that day.
(Cron jobs may delay for seconds, especially when the system load is high)
See commit 05bb3eb ("Change update_online to do same way as pwcu does.")
for details.
In order to address this issue,
commits f1328b3 ("Fix calculation error in update_online.", 2014-12-23 (UTC+8))
and d38b21d ("Fix update_online again, to avoid timezone problems.", 2014-12-24 (UTC+8))
were made to redefine `base` as `time(0) - DAY_SECONDS`.
The relevant logic somehow reverted to using the logic in commit 6871fbb ("Update using ulist.").
However, the condition `urec.lastlogin >= base` did not revert accordingly
and became arithmetically equivalent to `urec.lastlogin + DAY_SECONDS >= now`,
which does exclude users whose online duration = 1 day.
Since update_online runs every 1 day in the current system configuration,
the users' online duration between 2 successive runs cannot exceed 1 day
(assume that cron jobs have the same delay in every run).
In other words, when the users' lastlogin was reset in an update_online run,
their login count would not increase in the next update_online run,
which made their login count only increase by 1 every 2 days.
This issue is fixed by changing this condition to `urec.lastlogin > base`
to allow users with online duration = 1 day to have their login count increased.
---
* mbbsd/passwd.c:
* pwcuExitSave():
* Check the user's online duration at logout
* If the duration reaches N days,
increase the login count by N and lastlogin by N days
* util/update_online.c:
* fastcheck():
* Do not exclude users whose online duration = 1 day
from login count increment
* If the duration reaches N days,
increase the login count by N and lastlogin by N days
* Introduce variable `days`
for the reached number of days of the online duration
* main():
* Drop the assignment of now-unused variable `now`
IepIweidieng
added a commit
to IepIweidieng/pttbbs
that referenced
this issue
Jun 15, 2021
The method for increasing user's login count has been refined
to prevent undercounting of the login times. It works as follows:
* Login time increment at login (the same as the current method)
For users who haven't logged in today, increase their login count by 1 at login.
* Login time increments according to the online duration
When either update_online runs *or the user logs out*,
if the user's online duration reaches N days (>= N⋅86400 seconds),
increase the user's login count by N and the user's lastlogin by N days.
(Increasing lastlogin by N days makes the online duration decrease by N days)
Compare it to the current method:
* The online duration is not checked at logout -> is checked at logout
* Increment is performed only when the online duration *exceeds* 1 day (> 86400 seconds).
-> is performed also when the duration reaches 1 day (= 86400 seconds)
* Explained below as the login count increment rate issue
* The login count only increases by 1 -> can increase by N
* lastlogin is set to the current time (resets the online duration to 0)
-> lastlogin is increased by N days (reduces the online duration by N days)
* A reset would cause users to lose some of their online duration,
enough to cause undercounting.
* The reset method is also prone to unpredictable cron job delays.
Executing update_online is no longer necessary to increase users' login count
but is still needed to minimize users' loss of login times
due to abnormal termination of their session.
---
The login count increment rate issue
resulted from the slightly flawed condition for excluding users from increment.
The condition should exclude users whose online duration < 1 day.
When update_online was introduced on 2014-03-25 (UTC+8),
this condition was wrongly flipped as `u->lastlogin + DAY_SECONDS <= now`.
It was corrected within an hour to be `now < urec.lastlogin + DAY_SECONDS`
(equivalently `urec.lastlogin + DAY_SECONDS > now`).
See commits 4f69140 ("Add utility to update user online counter (lastlogin/numlogindays).")
and 6871fbb ("Update using ulist.") for details.
A 1-hour tolerance of online duration was soon introduced and cancelled.
See commit 05702e5 ("update_online: prevent too verbose messages and allow some tolerance in duration.").
Within 1 day, another commit changed this condition to `urec.lastlogin >= base`,
where `base` was defined as 09:40 of the current day (in the local time zone).
It may have meant to increase the login count for users logged in before 09:40.
This was stated to be inspired by the login time increment at login.
However, update_online seems to have run at 00:00 of the day at that time.
This made the condition always false since 09:40 would be a time in the future,
and thus all online users' login count were increased unconditionally.
This caused overcounting of the login times, as users might manage to log in
at 00:00 and before update_online ran, thus getting 2 login times on that day.
(Cron jobs may delay for seconds, especially when the system load is high)
See commit 05bb3eb ("Change update_online to do same way as pwcu does.")
for details.
In order to address this issue,
commits f1328b3 ("Fix calculation error in update_online.", 2014-12-23 (UTC+8))
and d38b21d ("Fix update_online again, to avoid timezone problems.", 2014-12-24 (UTC+8))
were made to redefine `base` as `time(0) - DAY_SECONDS`.
The relevant logic somehow reverted to using the logic in commit 6871fbb ("Update using ulist.").
However, the condition `urec.lastlogin >= base` did not revert accordingly
and became arithmetically equivalent to `urec.lastlogin + DAY_SECONDS >= now`,
which does exclude users whose online duration = 1 day.
Since update_online runs every 1 day in the current system configuration,
the users' online duration between 2 successive runs cannot exceed 1 day
(assume that cron jobs have the same delay in every run).
In other words, when the users' lastlogin was reset in an update_online run,
their login count would not increase in the next update_online run,
which made their login count only increase by 1 every 2 days.
This issue is fixed by changing this condition to `urec.lastlogin > base`
to allow users with online duration = 1 day to have their login count increased.
---
* mbbsd/passwd.c:
* pwcuExitSave():
* Check the user's online duration at logout
* If the duration reaches N days,
increase the login count by N and lastlogin by N days
* util/update_online.c:
* fastcheck():
* Do not exclude users whose online duration = 1 day
from login count increment
* If the duration reaches N days,
increase the login count by N and lastlogin by N days
* Introduce variable `days`
for the reached number of days of the online duration
* main():
* Drop the assignment of now-unused variable `now`
IepIweidieng
added a commit
to IepIweidieng/pttbbs
that referenced
this issue
Jun 15, 2021
The method for increasing user's login count has been refined
to prevent undercounting of the login times. It works as follows:
* Login time increment at login (the same as the current method)
For users who haven't logged in today, increase their login count by 1 at login.
* Login time increments according to the online duration
When either update_online runs *or the user logs out*,
if the user's online duration reaches N days (>= N⋅86400 seconds),
increase the user's login count by N and the user's lastlogin by N days.
(Increasing lastlogin by N days makes the online duration decrease by N days)
Compare it to the current method:
* The online duration is not checked at logout -> is checked at logout
* Increment is performed only when the online duration *exceeds* 1 day (> 86400 seconds)
-> is performed also when the duration reaches 1 day (= 86400 seconds)
* Explained below as the login count increment rate issue
* The login count only increases by 1 -> can increase by N
* lastlogin is set to the current time (resets the online duration to 0)
-> lastlogin is increased by N days (reduces the online duration by N days)
* A reset would cause users to lose some of their online duration,
enough to cause undercounting.
* The reset method is also prone to unpredictable cron job delays.
Executing update_online is no longer necessary to increase users' login count
but is still needed to minimize users' loss of login times
due to abnormal termination of their session.
---
The login count increment rate issue
resulted from the slightly flawed condition for excluding users from increment.
The condition should exclude users whose online duration < 1 day.
When update_online was introduced on 2014-03-25 (UTC+8),
this condition was wrongly flipped as `u->lastlogin + DAY_SECONDS <= now`.
It was corrected within an hour to be `now < urec.lastlogin + DAY_SECONDS`
(equivalently `urec.lastlogin + DAY_SECONDS > now`).
See commits 4f69140 ("Add utility to update user online counter (lastlogin/numlogindays).")
and 6871fbb ("Update using ulist.") for details.
A 1-hour tolerance of online duration was soon introduced and cancelled.
See commit 05702e5 ("update_online: prevent too verbose messages and allow some tolerance in duration.").
Within 1 day, another commit changed this condition to `urec.lastlogin >= base`,
where `base` was defined as 09:40 of the current day (in the local time zone).
It may have meant to increase the login count for users logged in before 09:40.
This was stated to be inspired by the login time increment at login.
However, update_online seems to have run at 00:00 of the day at that time.
This made the condition always false since 09:40 would be a time in the future,
and thus all online users' login count were increased unconditionally.
This caused overcounting of the login times, as users might manage to log in
at 00:00 and before update_online ran, thus getting 2 login times on that day.
(Cron jobs may delay for seconds, especially when the system load is high)
See commit 05bb3eb ("Change update_online to do same way as pwcu does.")
for details.
In order to address this issue,
commits f1328b3 ("Fix calculation error in update_online.", 2014-12-23 (UTC+8))
and d38b21d ("Fix update_online again, to avoid timezone problems.", 2014-12-24 (UTC+8))
were made to redefine `base` as `time(0) - DAY_SECONDS`.
The relevant logic somehow reverted to using the logic in commit 6871fbb ("Update using ulist.").
However, the condition `urec.lastlogin >= base` did not revert accordingly
and became arithmetically equivalent to `urec.lastlogin + DAY_SECONDS >= now`,
which does exclude users whose online duration = 1 day.
Since update_online runs every 1 day in the current system configuration,
the users' online duration between 2 successive runs cannot exceed 1 day
(assume that cron jobs have the same delay in every run).
In other words, when the users' lastlogin was reset in an update_online run,
their login count would not increase in the next update_online run,
which made their login count only increase by 1 every 2 days.
This issue is fixed by changing this condition to `urec.lastlogin > base`
to allow users with online duration = 1 day to have their login count increased.
---
* mbbsd/passwd.c:
* pwcuExitSave():
* Check the user's online duration at logout
* If the duration reaches N days,
increase the login count by N and lastlogin by N days
* util/update_online.c:
* fastcheck():
* Do not exclude users whose online duration = 1 day
from login count increment
* If the duration reaches N days,
increase the login count by N and lastlogin by N days
* Introduce variable `days`
for the reached number of days of the online duration
* main():
* Drop the assignment of now-unused variable `now`
IepIweidieng
added a commit
to IepIweidieng/pttbbs
that referenced
this issue
Jun 8, 2023
…line users [ptt#104] The algorithm for increasing online users' login count has been improved, which fixes the issue that the increment was sometimes done only per 2 days. When update_online was introduced in 4f69140 ("Add utility to update user online counter (lastlogin/numlogindays).", 2014-03-25 (UTC+8)), the condition for excluding users from an update by their online duration was wrongly flipped as `u->lastlogin + DAY_SECONDS <= now` but had been corrected within 1 hour into `now < urec.lastlogin + DAY_SECONDS` (equivalently `urec.lastlogin + DAY_SECONDS > now`) in 6871fbb ("Update using ulist."). A 1-hour tolerance of online duration was soon introduced in 05702e5 ("update_online: prevent too verbose messages and allow some tolerance in duration.") but had soon been cancelled. Within 1 day, 05bb3eb ("Change update_online to do same way as pwcu does.") changed this condition into `urec.lastlogin >= base`, where `base` was 09:40 of the current day (in the local time zone). However, update_online seems to have run at 00:00 every day for PTT, which made the condition always false, and thus all online users' login count were increased unconditionally. This had allowed the users to earn 2 login count within a day by logging in at 00:00 and before update_online ran. (Note that Cron can lags due to a high system load) Therefore, f1328b3 ("Fix calculation error in update_online.", 2014-12-23 (UTC+8)) and d38b21d ("Fix update_online again, to avoid timezone problems.", 2014-12-24 (UTC+8)) redefined `base` as `time(0) - DAY_SECONDS`, which has partially reverted the logic to 6871fbb ("Update using ulist."). However, the condition `urec.lastlogin >= base` was not reverted accordingly and has become equivalent to `urec.lastlogin + DAY_SECONDS >= now`, which does exclude users whose online duration = 1 day. This has caused online users' login count increase only by 1 per 2 days (assume that Cron did not lag). In the new algorithm, users' increment of login count is first calculated, then users whose login count do not increase are excluded, and then their login time and count are advanced/increased accordingly. It works regardless of the time and frequency that update_online runs. To account for the possible lagging of Cron, the reference time is now `now`, the nearest minute in the past from now. Because updating users' login count at pwcuExitSave() would cause unwanted logs, perform such updating at logout is not considered. Instead, to minimize online user's possible loss of login count, update_online can be excuted multiple times per day. * fastcheck() * add local `now` for the nearest minute in the past * add local `days` for the count of days since `urec.lastlogin` until `now` * make `urec.lastlogin` advance by `days * DAY_SECONDS` instead of reset to `now` * make `urec.numlogindays` increase by `days` instead of fixed 1 * main() * drop the assignment of now-unused global `now`
IepIweidieng
added a commit
to IepIweidieng/pttbbs
that referenced
this issue
Jun 8, 2023
…line users [ptt#104] The algorithm for increasing online users' login count has been improved, which fixes the issue that the increment was sometimes done only per 2 days. When update_online was introduced in 4f69140 ("Add utility to update user online counter (lastlogin/numlogindays).", 2014-03-25 (UTC+8)), the condition for excluding users from an update by their online duration was wrongly flipped as `u->lastlogin + DAY_SECONDS <= now` but had been corrected within 1 hour into `now < urec.lastlogin + DAY_SECONDS` (equivalently `urec.lastlogin + DAY_SECONDS > now`) in 6871fbb ("Update using ulist."). A 1-hour tolerance of online duration was soon introduced in 05702e5 ("update_online: prevent too verbose messages and allow some tolerance in duration.") but had soon been cancelled. Within 1 day, 05bb3eb ("Change update_online to do same way as pwcu does.") changed this condition into `urec.lastlogin >= base`, where `base` was 09:40 of the current day (in the local time zone). However, update_online seems to have run at 00:00 every day for PTT, which made the condition always false, and thus all online users' login count were increased unconditionally. This had allowed the users to earn a login count of 2 within a day by logging in at 00:00 and before update_online ran. (Note that Cron can lags due to a high system load) Therefore, f1328b3 ("Fix calculation error in update_online.", 2014-12-23 (UTC+8)) and d38b21d ("Fix update_online again, to avoid timezone problems.", 2014-12-24 (UTC+8)) redefined `base` as `time(0) - DAY_SECONDS`, which has partially reverted the logic to 6871fbb ("Update using ulist."). However, the condition `urec.lastlogin >= base` was not reverted accordingly and has become equivalent to `urec.lastlogin + DAY_SECONDS >= now`, which does exclude users whose online duration = 1 day. This has caused online users' login count increase only by 1 per 2 days (assume that Cron did not lag). In the new algorithm, users' increment of login count is first calculated, then users whose login count do not increase are excluded, and then their login time and count are advanced/increased accordingly. It works regardless of the time and frequency that update_online runs. To account for the possible lagging of Cron, the reference time is now `now`, the nearest minute in the past from now. Because updating users' login count at pwcuExitSave() would cause unwanted logs, perform such updating at logout is not considered. Instead, to minimize online user's possible loss of login count, update_online can be excuted multiple times per day. * fastcheck() * add local `now` for the nearest minute in the past * add local `days` for the count of days since `urec.lastlogin` until `now` * make `urec.lastlogin` advance by `days * DAY_SECONDS` instead of reset to `now` * make `urec.numlogindays` increase by `days` instead of fixed 1 * main() * drop the assignment of now-unused global `now`
IepIweidieng
added a commit
to IepIweidieng/pttbbs
that referenced
this issue
Jun 8, 2023
…line users [ptt#104] The algorithm for increasing online users' login count has been improved, which fixes the issue that the increment was sometimes done only per 2 days. When update_online was introduced in 4f69140 ("Add utility to update user online counter (lastlogin/numlogindays).", 2014-03-25 (UTC+8)), the condition for excluding users from an update by their online duration was wrongly flipped as `u->lastlogin + DAY_SECONDS <= now` but had been corrected within 1 hour into `now < urec.lastlogin + DAY_SECONDS` (equivalently `urec.lastlogin + DAY_SECONDS > now`) in 6871fbb ("Update using ulist."). A 1-hour tolerance of online duration was soon introduced in 05702e5 ("update_online: prevent too verbose messages and allow some tolerance in duration.") but had soon been cancelled. Within 1 day, 05bb3eb ("Change update_online to do same way as pwcu does.") changed this condition into `urec.lastlogin >= base`, where `base` was 09:40 of the current day (in the local time zone). However, update_online seems to have run at 00:00 every day for PTT, which made the condition always false, and thus all online users' login count were increased unconditionally. This had allowed the users to earn a login count of 2 within a day by logging in at 00:00 and before update_online ran. (Note that Cron can lags due to a high system load) Therefore, f1328b3 ("Fix calculation error in update_online.", 2014-12-23 (UTC+8)) and d38b21d ("Fix update_online again, to avoid timezone problems.", 2014-12-24 (UTC+8)) redefined `base` as `time(0) - DAY_SECONDS`, which had partially reverted the logic to 6871fbb ("Update using ulist."). However, the condition `urec.lastlogin >= base` was not reverted accordingly and had become equivalent to `urec.lastlogin + DAY_SECONDS >= now`, which does exclude users whose online duration = 1 day. This had caused online users' login count increase only by 1 per 2 days (assume that Cron did not lag). In the new algorithm, users' increment of login count is first calculated, then users whose login count do not increase are excluded, and then their login time and count are advanced/increased accordingly. It works regardless of the time and frequency that update_online runs. To account for the possible lagging of Cron, the reference time is now `now`, the nearest minute in the past from now. Because updating users' login count at pwcuExitSave() would cause unwanted logs, perform such updating at logout is not considered. Instead, to minimize online user's possible loss of login count, update_online can be excuted multiple times per day. * fastcheck() * add local `now` for the nearest minute in the past * add local `days` for the count of days since `urec.lastlogin` until `now` * make `urec.lastlogin` advance by `days * DAY_SECONDS` instead of reset to `now` * make `urec.numlogindays` increase by `days` instead of fixed 1 * main() * drop the assignment of now-unused global `now`
|
The current algorithm:
Demonstration Case 展示案例
The Login Count Increment Rate Issue 登入次數增加速率問題This issue resulted from the slightly flawed condition for excluding users from increment. The condition should exclude users whose online duration < 1 day. When For details, see:
A 1-hour tolerance of online duration was soon introduced but had soon been cancelled. Within 1 day, another commit changed this condition to However, (Cron jobs may delay for seconds, especially when the system load is high) For details, see:
In order to address this issue, the following commits redefined
The relevant logic partially reverted to commit 6871fbb ("Update using ulist."). However, the condition Since |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
有使用者對 2014 年底後實施的登入次數累計方法有以下疑問:
https://www.ptt.cc/bbs/PttBug/M.1622376938.A.CC0.html
故把問題轉錄過來，也順便請教看看其他開發者對此有什麼看法?
The text was updated successfully, but these errors were encountered: