session timeout problem, timezone related, external database?

[John Sellens]

Hi - brand new, couldn't find this mentioned elsewhere.

I was trying to set up minarca with a postgresql database, and web logins
seemed to succeed, but then immediately go back to the login web page.

I *think* this is because of a timezone problem.
- I'm near Toronto - timezone EDT (UTC-4)
- The postgresql server is running with that timezone
- Seems to happen with a web server timezone of UTC or EDT.

I tried to find this in the code, but I'm not a python-person, and I'm
not familiar with the data model/database code, and wasn't successful.

The sessions table in postgresql had:
ExpirationTime | 2025-09-30 13:22:39.734123
AccessTime | 2025-09-30 13:13:39.731172
for login at 13:13 EDT. (Incidentally, I wasn't expecting those
to be 9 minutes apart - I think the docs say session-idle-timeout
defaults to 10 minutes.)

The fields are "timestamp without time zone". My *guess* is that
the code is assuming those are UTC, and in my case, they are local time.

Using sqlite works fine - it seems to have UTC times in the sessions
table even if the web server is EDT.

I *think* this may be somewhere in the rdiffweb code, but I wasn't able
to track it down.

I was able to workaround by setting long session timeouts:
session-idle-timeout=310
session-absolute-timeout=320

And yes, I know we should run our servers with UTC, but there's a bunch
of history in our environment, and it's not simple to change.

Why not just use sqlite? I'm looking to replace our urbackup installation,
which seems to fail too often with apparently corrupted sqlite tables,
so I'm being paranoid.

Hope this is helpful - thanks much!

John

[Patrik Dufresne]

Hello John,

Thanks for reaching out about this issue. The time zone should clearly not affect how the session expired.

When debugging timezone issue, it's always hard as we don't know where the mismanaged timezone occur in the code, when writing into a database or when reading from a database. To help me debug this with you, I would suggest you take a screen capture of postgresql data as you did. In addition, if you could take a screen capture of the user's session from the web interface too. That should help me investigate.

e.g.:

And please include the date & time when you took the screen capture.

Could you also confirm the version you are running ?

P.S.: I'm also from Canada ! 🇨🇦

--
You received this message because you are subscribed to the Google Groups "Minarca Data Backup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minarca+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/minarca/aNyHL9GKO4of7bDf%40syonex.com.

--

ATTENTION : Je serai en vacances du 16 oct au 26 oct 2025.
ATTENTION: I will be on vacation from Oct 16 to Oct 26, 2025.

IKUS Software

https://www.ikus-soft.com/

514-971-6442

St-Colomban, QC J5K 1T9

[Patrik Dufresne]

I double check to be sure. All timestamps are stored as UTC in SQLite or PostgreSQL.

[John Sellens]

Hi Patrik, thanks much for your replies, and for minarca.

In my environment, session timestamps in postgresql are not UTC, they
are EDT. My postgresql server has EDT as the server timezone, and a
query of "select now();" returns the EDT time. My guess might be that
your postgresql server runs as UTC, or has a database or postgresql
timezone set?

I just logged in at 13:29 EDT with
session-idle-timeout=310
session-absolute-timeout=320

Postgresql says
ExpirationTime | 2025-10-01 18:38:19.947676
AccessTime | 2025-10-01 13:29:19.807461
which are the appropriate times in EDT.

In the web interface Admin area / User Sessions the last accessed and
signed in values are "5 seconds ago" (as expected) and the Expiration
Time shows as 2025-10-01, 2:38:13 p.m. So the web converts from
presumed UTC to local EDT.

I tried
alter database minarca set timezone to 'UTC';
and restarted postgresql, but the values ended up being the same.

To recap: my observation is the session times get stored in sqlite
as UTC, postgresql as EDT (local), and the web code assumes that
the session.ExpirationTime field is UTC, and adjusts acccordingly.

Postgresql default timezone seems to be settable per-database,
or per-session.

Versions: minarca 6.1.2, ubuntu 24.04, postgresql 15.10 on other server.

I have a workaround (long session times), or I could use sqlite,
so count me a happy camper.

Hope this is helpful - thanks!

John

| > *ATTENTION : Je serai en vacances du 16 oct au 26 oct 2025. ATTENTION: I
| > will be on vacation from Oct 16 to Oct 26, 2025.*

| > IKUS Software
| > https://www.ikus-soft.com/
| > 514-971-6442
| > St-Colomban, QC J5K 1T9
| >
|
|
| --
|

| *ATTENTION : Je serai en vacances du 16 oct au 26 oct 2025. ATTENTION: I
| will be on vacation from Oct 16 to Oct 26, 2025.*

| IKUS Software
| https://www.ikus-soft.com/
| 514-971-6442
| St-Colomban, QC J5K 1T9
|
| --

| You received this message because you are subscribed to the Google Groups "Minarca Data Backup" group.
| To unsubscribe from this group and stop receiving emails from it, send an email to minarca+u...@googlegroups.com.

| To view this discussion visit https://groups.google.com/d/msgid/minarca/CAM%3D_CK7hK9vfTG7%2BmfzgQ2Lm%2BfAS_v0xvE9VhjnJpoAbMjei5A%40mail.gmail.com.

[Patrik Dufresne]

Hello John,

I'm starting to believe everything on the database side. Regardless of what the postgresql data show, the server stores and restores the proper value. But the session might get deleted during the clearing process.

Could you restore the default session timeout and enable the debug log with "debug=1". This should log the SQL statement. The session should get clear every 5 minutes.

To view this discussion visit https://groups.google.com/d/msgid/minarca/aN1sjDHrEkvrHpxK%40syonex.com.

--

ATTENTION : Je serai en vacances du 16 oct au 26 oct 2025.
ATTENTION: I will be on vacation from Oct 16 to Oct 26, 2025.