You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
function handleStartup() {
# These are idempotent, run them anyway
- /opt/kimai/bin/console -n kimai:install+ /opt/kimai/bin/console -n kimai:install --no-cache
/opt/kimai/bin/console -n kimai:update
if [ ! -z "$ADMINPASS" ] && [ ! -a "$ADMINMAIL" ]; then
/opt/kimai/bin/console kimai:user:create superadmin "$ADMINMAIL" ROLE_SUPER_ADMIN "$ADMINPASS"
fi
echo "$KIMAI" > /opt/kimai/var/installed
echo "Kimai2 ready"
}
By-pass the cache during update
The command kimai:update does not have a no-cache options. It could be added similar to the kimai:install command.
Proposed diff
protected function configure(): void
{
$this
->setDescription('Update your Kimai installation')
->setHelp('This command will execute all required steps to update your Kimai installation.')
+ ->addOption('no-cache', null, InputOption::VALUE_NONE, 'Skip cache re-generation')
;
}
protected function execute(InputInterface $input, OutputInterface $output): int
{
$io = new SymfonyStyle($input, $output);
$io->title('Kimai updates running ...');
$environment = $this->kernelEnvironment;
// make sure database is available, Kimai running and installed
try {
if (!$this->connection->createSchemaManager()->tablesExist(['kimai2_users', 'kimai2_timesheet'])) {
$io->error('Tables missing. Did you run the installer already?');
return Command::FAILURE;
}
if (!$this->connection->createSchemaManager()->tablesExist(['migration_versions'])) {
$io->error('Unknown migration status, aborting database update');
return Command::FAILURE;
}
} catch (ConnectionException $e) {
$io->error(['Database connection could not be established.', $e->getMessage()]);
return Command::FAILURE;
} catch (\Exception $ex) {
$io->error(['Failed to validate database.', $ex->getMessage()]);
return Command::FAILURE;
}
// execute latest doctrine migrations
try {
$command = $this->getApplication()->find('doctrine:migrations:migrate');
$cmdInput = new ArrayInput(['--allow-no-migration' => true]);
$cmdInput->setInteractive(false);
if (0 !== $command->run($cmdInput, $output)) {
throw new \RuntimeException('CRITICAL: problem when migrating database');
}
$io->writeln('');
} catch (\Exception $ex) {
$io->error($ex->getMessage());
return Command::FAILURE;
}
+ if (!$input->getOption('no-cache')) {
// flush the cache, in case values from the database are cached
$cacheResult = $this->rebuildCaches($environment, $io, $input, $output);
if ($cacheResult !== Command::SUCCESS) {
$io->warning(
[
sprintf('Updated %s to version %s but the cache could not be rebuilt.', Constants::SOFTWARE, Constants::VERSION),
'Please run the cache commands manually:',
'bin/console cache:clear --env=' . $environment . PHP_EOL .
'bin/console cache:warmup --env=' . $environment
]
);
} else {
$io->success(
sprintf('Congratulations! Successfully updated %s to version %s', Constants::SOFTWARE, Constants::VERSION)
);
}
+ }
return Command::SUCCESS;
}
Alternative
As an alternative, the kimai:update could store the result of the doctrine:migrations:migrate command (see where below) and rebuild the cache only if migrations were executed.
As shown in the documentation (https://www.kimai.org/documentation/docker-compose.html), I used the ADMINMAIL and ADMINPASS environment variables to create the super user. However, on each restart I get error messages in the log [ERROR] email: This e-mail address is already in use. and [ERROR] username: The username is already used..
Not sure how it could be improved though. However, seeing the [ERROR] tag while I was trying to figure out why Kimai didn't work (due to long restart time) made me think that the container exited at that moment. Maybe adding an ignore-error option to the command to be used in the handleStartup() command?
By-pass the cache during reload
Same idea as the kimai:reload command above. However, that would leave us with no cache rebuild. So maybe we could keep that one as-is as a single cache rebuild?
Describe your setup and add your Docker compose file (redact your credentials)
Environment
Host: linux x86_64 Ubuntu 22.04.4 LTS VM hosted on Proxmox
CPU: 4x @ 3.33GHz (virtualized as kmv64 on the VM)
Memory: 12.5 GB
Docker: 26.1.1 (API: 1.45)
Docker Compose: TBD (deployed via Portainer CE 2.20.2)
nfs shares are known for their terrible performance. That was the case 10+ years ago with Virtualbox and is likely the reason for your performance issues still today. Try to use a local mount and report the start time.
If a new version was deployed it is necessary to clear the cache, it has nothing to do with the migrations.
I did a docker rebuild/restart on a customer Synology today and it took ... don't exactly know, but definitely less than a minute.
Sorry, did not have time yet. Life got really busy. You can keep waiting for feedback label. But I am pretty sure you are right about the NFS share. I've seen a lot of slowing down in all apps that I transfered on the NFS lately.
Describe the problem
Problem
When restarting a stack, the
handleStartup()
andrunServer()
commands take a long time to complete.In my last restart:
+ /opt/kimai/bin/console -n kimai:install
took 5 minutes to complete at the clearing cache step.+ /opt/kimai/bin/console -n kimai:update
took 4 minutes to complete at the clearing cache step.+ /opt/kimai/bin/console kimai:reload --env=prod
took 5 minutes to complete at the clearing cache step.Steps
Ideas
By-pass the cache during install
The command
kimai:install
has ano-cache
options. It could be used in .docker/service.sh#L35-L44.Proposed diff
By-pass the cache during update
The command
kimai:update
does not have ano-cache
options. It could be added similar to thekimai:install
command.Proposed diff
Alternative
As an alternative, the
kimai:update
could store the result of thedoctrine:migrations:migrate
command (see where below) and rebuild the cache only if migrations were executed.kimai/src/Command/UpdateCommand.php
Line 77 in 93ca983
Improve super admin creation
As shown in the documentation (https://www.kimai.org/documentation/docker-compose.html), I used the
ADMINMAIL
andADMINPASS
environment variables to create the super user. However, on each restart I get error messages in the log[ERROR] email: This e-mail address is already in use.
and[ERROR] username: The username is already used.
.kimai/.docker/service.sh
Lines 39 to 41 in 93ca983
Not sure how it could be improved though. However, seeing the
[ERROR]
tag while I was trying to figure out why Kimai didn't work (due to long restart time) made me think that the container exited at that moment. Maybe adding anignore-error
option to the command to be used in thehandleStartup()
command?By-pass the cache during reload
Same idea as the
kimai:reload
command above. However, that would leave us with no cache rebuild. So maybe we could keep that one as-is as a single cache rebuild?Describe your setup and add your Docker compose file (redact your credentials)
Environment
Docker Compose
Logs
This is from my last restart.
Command used to run the container
No response
The text was updated successfully, but these errors were encountered: