KevinTheJedi

PHP settings are good, we have been using OSTicket for years no problem.
We do have our own mod's in it but nothing major.
Just checked we have the latest branch merged on git.
At best estimate we think it might have started around about the time we merged in
https://github.com/osTicket/osTicket/commit/3dd2ed35f3bfd2f061f46395b5a863b40c3f97a9
or
https://github.com/osTicket/osTicket/commit/4689926b2d3d25754f0ddcf8d4e181a2817f6d56

Hopefully this helps, i'll test the agent sessions = 0 and see if we have more issues, but might take me a week to say either way

hsaartet

Well none of those commits relate to attachments so those are not it. Unless you mean when you merged up to those commits.

Cheers.

KevinTheJedi

yes, it would be merging up to those commits..... before that we would have been running https://github.com/osTicket/osTicket/commit/724de4563e736cdde7c2e2dabe839b232eb5438f

we tend to upgrade in stages as we see something important in the releases rather than doing every update!

hsaartet

I just went through all the changes from v1.18 -> v1.18.1 and there isn't much (if any) that would affect file uploads for Agents. You can compare the two branches here yourself to see:

• https://github.com/osTicket/osTicket/compare/v1.18...v1.18.1

Cheers.

Hi Kevin
I'm not a developer by any means, but you noted above about 'agent sessions' and such and i note there is a commit
https://github.com/osTicket/osTicket/commit/2b5fa48590cff705e38aaeb9c77d42d7980cc73c

which seems to change the way sessions are handled.

This is intermittent, so its gonna be hard to track down, but once i have finished the agent session timeout experiment, I'll try another reversing that commit unless you can think of anything terrible about that idea.

Regards

So, we tried the 'Agent Session Timeout = 0 now, it was previously set to 43830.' option and this has not fixed it.

Any further ideas on this,

As mentioned the core issues is agents attaching files to posts, hitting reply and the attachment is gone and doesn't send, they can immediately repeat this and it works fine 2nd time.

hsaartet

That definitely sounds like session issues then. After work hours, TRUNCATE the entire _session table. It's important to do this after-hours as it will kill any active sessions. Once you truncate the table you can have your Agents completely clear their cache/cookies, log in, and retest.

Cheers.

Hi Kevin, thanks for the help, the issue is extremely intermittent.
We only have 7 users and really only attach files 2-3 times a day, we might get a fault once or twice a week.
Should we be looking at truncating that table nightly? or once off?
Regards

hsaartet

You should have a cron job configured so the system will routinely clean expired sessions. This happens on auto-cron too (I believe) but will happen way more seldomly than a reoccurring cron job.

Cheers.

hsaartet

That should be it. Hmmm the only other thing I can think of is something like this:

• https://forum.osticket.com/d/104368-login-page-refreshes-in-osticket-v1181

People with session issues typically change their webserver from PREFORK to FAST_CGI and that resolves their issues. I cannot guarantee this will fix it but this is the only other thing I can think of right now.

Cheers.

OK, I switched from apache FPM to FastCGI, thats a quick enough change, i'll truncate the table tonight and see where we get from there.

truncated the sessions table..... now we just get

No input file specified.

OK, we use entraid login, which died with Apache fastcgi.... switched back to Apache FPM and working.....

Hi,

we have exact the same problem!
Attachments randomly missing.
We cannot reproduce it safely. Sometimes it works, sometimes not.

osTicket-Version v1.18.1 (0375576)
Server-Software Apache/2.4.29
MySQL-Version 5.7.42
PHP-Version 8.2.7

Red_Peace
Our issue is still ongoing, we havnt isolated it yet, we need to try apachi fastcgi again, but havent had time.

Recently we got the issue

Información del servidor
Versión osTicket v1.18.1 (0375576) — v1.18.2 está disponible
Software del Servidor Web Apache/2.4.57 (Debian)
Versión MySQL 10.5.27
Versión PHP 8.1.20