snipe / snipe-it

A free open source IT asset/license management system
https://snipeitapp.com
GNU Affero General Public License v3.0
11.19k stars 3.2k forks source link

Snipe-it upgrade from v6.2.3 to v7.0.13 fails #15790

Open HIS-David opened 2 weeks ago

HIS-David commented 2 weeks ago

Debug mode

Describe the bug

We are using Snipe-It version 6.2.3 and are trying to upgrade to 7.0.13 but are having an issue with the database migration of "2023-12-14-032522_add_remote_ip_and_action_source_to_action_logs" due to max time execution exceeding 600 seconds. We have around 5 million records in the action_logs table so will take a bit longer than 10 minutes.

image

We have tried to update the php.ini with the following to see if we could pass this 600 seconds limit. max_execution_time = 1200 max_execution_time = 0 memory_limit = 512M

Reproduction steps

  1. We have tried by installing a vanilla 7.0.13 and restoring the database and migrate but same issue occurred.
  2. Updated php.ini with max_execution_time = 1200, max_execution_time = 0, memory_limit = 512M to try to get past the 600 sec limit.
  3. Check dependencies files.
  4. Delete first year of action_log records to reduce overall size of table. This allowed the system to upgrade but had server 500 errors when updating any asset after migration had completed.

Expected behavior

attached update log and laravel log Laravel.txt updatelog.txt

Screenshots

No response

Snipe-IT Version

6.2.3

Operating System

Windows

Web Server

IIS

PHP Version

8.1.28

Operating System

Windows

Browser

Edge

Version

130.0.2849.68

Device

n/a

Operating System

n/a

Browser

n/a

Version

n/a

Error messages

[2024-11-08 15:40:52] production.ERROR: Symfony\Component\ErrorHandler\Error\FatalError: Maximum execution time of 600 seconds exceeded in D:\snipe-it\vendor\laravel\framework\src\Illuminate\Database\Connection.php:587
Stack trace:
#0 {main}  
[2024-11-08 15:40:52] production.ERROR: Maximum execution time of 600 seconds exceeded {"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\FatalError(code: 0): Maximum execution time of 600 seconds exceeded at D:\\snipe-it\\vendor\\laravel\\framework\\src\\Illuminate\\Database\\Connection.php:587)
[stacktrace]
#0 {main}
"}

Additional context

No response

welcome[bot] commented 2 weeks ago

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

snipe commented 1 week ago

I think the best route here (which is awful) is to manually add those columns and then insert the migration into the migrations table so it gets skipped on the next time around. It's odd that it would take too long when it's just adding the columns, not actually populating them with data - and 5 million isn't even really that much for MySQL.

Maybe @uberbrady has a better suggestion though.

uberbrady commented 1 week ago

This doesn't make sense - on most new-ish versions of MySQL, adding a nullable field as the last column is optimized to run very quickly. I suspect if you do the appropriate ALTER TABLE blah ADD COLUMN and see how long each of those statements take, you'll get a better idea. I imagine each one of those ALTER statements will be relatively slow, and adding up the time for all three will exceed the 10 minutes.

But I don't understand why. Maybe really 'slow' storage?

Also the editing of the php.ini should have helped - if you do php -i | grep max_execution_time it should say your longer value. I'm not finding any places in Laravel itself where the max execution time is being adjusted, in grep'ing through the source.

So, in short - I don't know why this is happening; it shouldn't, on a few different levels. But @snipe 's workaround should work.

snipe commented 6 days ago

Hi there - any updates?

HIS-David commented 6 days ago

Hi there - any updates?

Planning on trying again this afternoon. Should have an update tomorrow morning.

HIS-David commented 4 days ago

I upgraded the server to PHP 8.3.14 and MariaDB 10.5.27.0 and changed the php.ini settings back to the default.

image

This got us past the 2023_12-14_032522_add_remote_ip_and_action_source_to_action_logs migration but are now stuck on the following.

image

Not sure how to re-run the migration as if i do "php artisan migrate" it just fails at the same section.

snipe commented 4 days ago

You can manually add that migration to the migrations table, and then re-run migrations.

HIS-David commented 4 days ago

I'm not sure how to do that. Any pointers would be great. Thanks.