Bug - Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker-10 There was an error executing FormIDCleanUp() in Kernel::System::Web::UploadCache -- Error deserializing data

[fkffm]

Environment

• Server OS: Linux (Debian GNU/Linux 12 (bookworm))
• Znuny version: znuny-6.5.11
• Database: PostgreSQL

Expected behavior

No error message.

Actual behavior

Every hour we get the following error message:

Feb 12 09:46:12 lxtts7 OTRS-otrs.Daemon.pl - Daemon Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker-10[3357344]: [Error][Kernel::System::Daemon::DaemonModules::BaseTaskWorker::_HandleError][Line:53]: There was an error executing FormIDCleanUp() in Kernel::System::Web::UploadCache: ERROR: OTRS-otrs.Daemon.pl - Daemon Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker-10 Perl: 5.36.0 OS: linux Time: Wed Feb 12 09:46:12 2025#012#012 Message: Error deserializing data: #012#012 Traceback (3357344): #012 Module: Kernel::System::Storable::Deserialize Line: 122#012 Module: Kernel::System::FormDraft::FormDraftGet Line: 199#012 Module: Kernel::System::Web::UploadCache::FS::FormIDCleanUp Line: 445#012 Module: Kernel::System::Web::UploadCache::FormIDCleanUp Line: 182#012 Module: (eval) Line: 143#012 Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Cron::Run Line: 122#012 Module: Kernel::System::Daemon::DaemonModules::SchedulerTaskWorker::Run Line: 236#012 Module: (eval) Line: 332#012 Module: main::Start Line: 332#012 Module: /opt/otrs/bin/otrs.Daemon.pl Line: 153#012

How to reproduce

It's a cronjob

$Self->{'Daemon::SchedulerCronTaskManager::Task'}->{'WebUploadCacheCleanup'} =  {
  'Function' => 'FormIDCleanUp',
  'MaximumParallelInstances' => '1',
  'Module' => 'Kernel::System::Web::UploadCache',
  'Params' => [],
  'Schedule' => '46 * * * *',
  'TaskName' => 'WebUploadCacheCleanup'
};

Additional information

We migrated from MySQL to a PostgreSQL cluster, and since then, this error message has appeared. Changing the WebUploadCacheModule does not resolve the issue either.

$Self->{'WebUploadCacheModule'} =  'Kernel::System::Web::UploadCache::DB';
$Self->{'WebUploadCacheModule'} =  'Kernel::System::Web::UploadCache::FS';

[hanneshal]

Hi, I think we talked about this in Discord right?
You can contact us at community@znuny.com and we schedule a remote session.
We do not have this problem in the standard either with postgresql nor maria/mysql.
So it is most likely related to the migration

Regards

[fkffm]

Hi, someone else must have the same problem, I haven't been on Discord so far.

Best regards

[hanneshal]

Ok, the Discord one is a bit different.

My guess is that the migration for serialized data was not a 100% success.
Have you tried to manually clean the table after the migration?

Regards

[fkffm]

Yes, I cleaned the table, and it's currently empty. However, I still received the error message a few minutes ago.

tts-s=> SELECT * FROM web_upload_cache;
 form_id | filename | content_id | content_size | content_type | disposition | content | create_time_unix 
---------+----------+------------+--------------+--------------+-------------+---------+------------------
(0 rows)

tts-s=> \d+ web_upload_cache;
                                            Table "tts.web_upload_cache"
      Column      |          Type          | Collation | Nullable | Default | Storage  | Stats target | Description 
------------------+------------------------+-----------+----------+---------+----------+--------------+-------------
 form_id          | character varying(250) |           |          |         | extended |              | 
 filename         | character varying(250) |           |          |         | extended |              | 
 content_id       | character varying(250) |           |          |         | extended |              | 
 content_size     | character varying(30)  |           |          |         | extended |              | 
 content_type     | character varying(250) |           |          |         | extended |              | 
 disposition      | character varying(15)  |           |          |         | extended |              | 
 content          | text                   |           | not null |         | extended |              | 
 create_time_unix | bigint                 |           | not null |         | plain    |              | 
Access method: heap

[hanneshal]

My bad ...the error message / stacktrace shows that FS is used.
Please check the content of var/tmp my guess is that there is a missmatch or even a permission issue.

Note: after you changed the sysconfig you need to stop the daemon and wait for it to restart

[fkffm]

The permissions look fine to me.

# ls -al /opt/otrs/var/tmp/
total 16
drwxrwsr-x  4 otrs www-data 4096 Feb 12 11:10 .
drwxrwsr-x 14 otrs www-data 4096 Oct  2 13:30 ..
drwxrws--- 65 otrs www-data 4096 Feb 12 10:45 CacheFileStorable
drwxrws---  2 otrs www-data 4096 Feb 12 09:28 upload_cache

# ls -al /opt/otrs/var/tmp/upload_cache/
total 8
drwxrws--- 2 otrs www-data 4096 Feb 12 09:28 .
drwxrwsr-x 4 otrs www-data 4096 Feb 12 11:10 ..

I didn't restart the daemon this morning, when switching to FS, but I'm doing it now. I'll wait and see if the error still occurs.

[fkffm]

I may have found out how to reproduce the problem.

If a customer starts creating a ticket through the web interface and uploads a file but does not finish creating the ticket, an error message appears at the 46th minute, when the cronjob runs.

The file stays in /var/tmp/upload_cache/, even if the creation process is canceled.

Shouldn't the following command clean up the folder? Tthe file is still there after running the command.

# su - otrs -s /bin/bash -c "bin/otrs.Console.pl Maint::WebUploadCache::Cleanup"
Cleaning up the upload cache files...
Done.

# ls -al /opt/otrs/var/tmp/upload_cache/
total 12
drwxrws--- 3 otrs     www-data 4096 Feb 12 12:45 .
drwxrwsr-x 4 otrs     www-data 4096 Feb 12 12:56 ..
drwxrws--- 2 www-data www-data 4096 Feb 12 12:45 1739360709.3552820.59950317

[hanneshal]

can you post a "id otrs" please.

[fkffm]

# id otrs
uid=114(otrs) gid=33(www-data) groups=33(www-data)

[fkffm]

Quick update:

It looks like an entry in the form_draft table was the problem.

tts-s=> select * from form_draft;
 id | object_type | object_id |       action       |  title  | content |     create_time     | create_by |     change_time     | change_by 
----+-------------+-----------+--------------------+---------+---------+---------------------+-----------+---------------------+-----------
 23 | Ticket      |      4040 | AgentTicketCompose | Antwort |         | 2025-02-07 09:07:01 |        13 | 2025-02-07 09:07:01 |        13
(1 row)

tts-s=> select tn from ticket where id=4040;
        tn        
------------------
 2024111110000065
(1 row)

Then, I deleted the draft in the web interface for Ticket 2024111110000065. So far, the error has not occurred again.

But I will test again to see if it happens when I create a new draft.

[hanneshal]

Interesting. This might be related to

1. The db change and the error that occured with the deserialization
2. Then the change, without daemon restart, may resulted in the confusion about this

I put this on hold. If nothing else comes up, we close it after a month of no activity

Thanks