Services not starting after reboot

hi
i’ve noticed that 3 services never start after reboot

  • clamav
  • mariadb
  • php8.1-fpm

Hestia was freshly installed on ubuntu 22.04
now up-to-date, version is 1.6.14
Contabo VPS 4cores 8Gigs

This is an image of hestia’s settings right after reboot:

I’ve read some threads about the same issue with NGINX
but not with the services i’m listing above

So far, I have to go to the panel et start them manually.
Then, services work just fine once they are started.

Thanks if you can help

Please check the log files of the related services, should be the point to start.

1 Like

/var/log/hestia/error.log

2023-02-09 09:06:06 v-log-user-login  'admin' '2a02:8440:5140:911:11fb:7dd3:225e:a6c8' 'failed' '96bfd2ad021acefaa9>
2023-02-09 09:06:27 v-log-user-login  'vps-admini' '2a02:8440:5140:911:11fb:7dd3:225e:a6c8' 'success' '9eddd8bcda6c>
2023-02-09 09:08:15 v-add-user-sftp-jail  'syslog' 'no' [Error 3]
2023-02-09 09:08:15 v-add-user-sftp-jail  'syslog' 'no' [Error 3]
2023-02-09 09:10:03 v-update-sys-rrd-mysql  'daily' [Error 15]
2023-02-09 09:15:02 v-update-sys-rrd-mysql  'daily' [Error 15]
2023-02-09 09:20:03 v-update-sys-rrd-mysql  'daily' [Error 15]
2023-02-09 09:25:02 v-update-sys-rrd-mysql  'daily' [Error 15]
2023-02-09 09:30:02 v-update-sys-rrd-mysql  'daily' [Error 15]
2023-02-09 09:35:02 v-update-sys-rrd-mysql  'daily' [Error 15]
2023-02-09 09:40:02 v-update-sys-rrd-mysql  'daily' [Error 15]
2023-02-09 09:45:51 v-add-user-sftp-jail  'syslog' 'no' [Error 3]
2023-02-09 09:45:51 v-add-user-sftp-jail  'syslog' 'no' [Error 3]
2023-02-09 09:46:57 v-update-sys-rrd-mysql  'daily' [Error 15]
2023-02-09 09:50:11 v-add-user-sftp-jail  'syslog' 'no' [Error 3]
2023-02-09 09:50:11 v-add-user-sftp-jail  'syslog' 'no' [Error 3]
2023-02-09 09:52:24 v-add-user-sftp-jail  'syslog' 'no' [Error 3]
2023-02-09 09:52:24 v-add-user-sftp-jail  'syslog' 'no' [Error 3]

/var/log/clamav.log

Thu Feb  9 05:05:30 2023 -> SelfCheck: Database status OK.
Thu Feb  9 05:40:00 2023 -> Waiting for all threads to finish
Thu Feb  9 05:40:22 2023 -> Shutting down the main socket.
Thu Feb  9 05:40:22 2023 -> Pid file removed.
Thu Feb  9 05:40:22 2023 -> --- Stopped at Thu Feb  9 05:40:22 2023
Thu Feb  9 05:40:22 2023 -> Closing the main socket.
Thu Feb  9 05:40:22 2023 -> Socket file removed.
Thu Feb  9 09:51:23 2023 -> +++ Started at Thu Feb  9 09:51:23 2023
Thu Feb  9 09:51:23 2023 -> Received 0 file descriptor(s) from systemd.
Thu Feb  9 09:51:23 2023 -> clamd daemon 0.103.6 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
Thu Feb  9 09:51:23 2023 -> Log file size limited to 4294967295 bytes.
Thu Feb  9 09:51:23 2023 -> Reading databases from /var/lib/clamav
Thu Feb  9 09:51:23 2023 -> Not loading PUA signatures.
Thu Feb  9 09:51:23 2023 -> Bytecode: Security mode set to "TrustSigned".
Thu Feb  9 09:51:43 2023 -> Loaded 8651924 signatures.
Thu Feb  9 09:51:47 2023 -> LOCAL: Unix socket file /var/run/clamav/clamd.ctl
Thu Feb  9 09:51:47 2023 -> LOCAL: Setting connection queue length to 15
Thu Feb  9 09:51:47 2023 -> Limits: Global time limit set to 120000 milliseconds.
Thu Feb  9 09:51:47 2023 -> Limits: Global size limit set to 104857600 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: File size limit set to 26214400 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: Recursion level limit set to 16.
Thu Feb  9 09:51:47 2023 -> Limits: Files limit set to 10000.
Thu Feb  9 09:51:47 2023 -> Limits: Core-dump limit is 0.
Thu Feb  9 09:51:47 2023 -> Limits: MaxEmbeddedPE limit set to 10485760 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxHTMLNormalize limit set to 10485760 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxHTMLNoTags limit set to 2097152 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxScriptNormalize limit set to 5242880 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxZipTypeRcg limit set to 1048576 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxPartitions limit set to 50.
Thu Feb  9 09:51:47 2023 -> Limits: MaxIconsPE limit set to 100.
Thu Feb  9 09:51:47 2023 -> Limits: MaxRecHWP3 limit set to 16.
Thu Feb  9 09:51:47 2023 -> Limits: PCREMatchLimit limit set to 10000.
Thu Feb  9 09:51:47 2023 -> Limits: Core-dump limit is 0.
Thu Feb  9 09:51:47 2023 -> Limits: MaxEmbeddedPE limit set to 10485760 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxHTMLNormalize limit set to 10485760 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxHTMLNoTags limit set to 2097152 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxScriptNormalize limit set to 5242880 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxZipTypeRcg limit set to 1048576 bytes.
Thu Feb  9 09:51:47 2023 -> Limits: MaxPartitions limit set to 50.
Thu Feb  9 09:51:47 2023 -> Limits: MaxIconsPE limit set to 100.
Thu Feb  9 09:51:47 2023 -> Limits: MaxRecHWP3 limit set to 16.
Thu Feb  9 09:51:47 2023 -> Limits: PCREMatchLimit limit set to 10000.
Thu Feb  9 09:51:47 2023 -> Limits: PCRERecMatchLimit limit set to 5000.
Thu Feb  9 09:51:47 2023 -> Limits: PCREMaxFileSize limit set to 26214400.
Thu Feb  9 09:51:47 2023 -> Archive support enabled.
Thu Feb  9 09:51:47 2023 -> AlertExceedsMax heuristic detection disabled.
Thu Feb  9 09:51:47 2023 -> Heuristic alerts enabled.
Thu Feb  9 09:51:47 2023 -> Portable Executable support enabled.
Thu Feb  9 09:51:47 2023 -> ELF support enabled.
Thu Feb  9 09:51:47 2023 -> Mail files support enabled.
Thu Feb  9 09:51:47 2023 -> OLE2 support enabled.
Thu Feb  9 09:51:47 2023 -> PDF support enabled.
Thu Feb  9 09:51:47 2023 -> SWF support enabled.
Thu Feb  9 09:51:47 2023 -> HTML support enabled.
Thu Feb  9 09:51:47 2023 -> XMLDOCS support enabled.
Thu Feb  9 09:51:47 2023 -> HWP3 support enabled.
Thu Feb  9 09:51:47 2023 -> Self checking every 3600 seconds.
Thu Feb  9 09:51:47 2023 -> Listening daemon: PID: 474
Thu Feb  9 09:51:47 2023 -> MaxQueue set to: 100

/var/log/php8.1-fpm.log
is empty

/var/log/mysql/error.log
no log since 2 days

Is this useful information?

Try starting the service first

yes, that’s what I did. I restarted the services, then copied the logs.

Any output with systemctl status mysql

Here it is:

● mariadb.service - MariaDB 10.6.11 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2023-02-09 09:51:24 CET; 1h 58min ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 510 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    Process: 529 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 533 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
    Process: 1017 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 1019 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
   Main PID: 667 (mariadbd)
     Status: "Taking your SQL requests now..."
      Tasks: 18 (limit: 9456)
     Memory: 269.2M
        CPU: 30.578s
     CGroup: /system.slice/mariadb.service
             └─667 /usr/sbin/mariadbd

Feb 09 09:51:23 hpanel.rez0.net systemd[1]: Starting MariaDB 10.6.11 database server...
Feb 09 09:51:24 hpanel.rez0.net mariadbd[667]: 2023-02-09  9:51:24 0 [Note] /usr/sbin/mariadbd (server 10.6.11-MariaDB-0ubuntu0.22.04.1) starting as process 667 ...
Feb 09 09:51:24 hpanel.rez0.net systemd[1]: Started MariaDB 10.6.11 database server.
Feb 09 09:51:24 hpanel.rez0.net /etc/mysql/debian-start[1024]: Upgrading MySQL tables if necessary.
Feb 09 09:51:24 hpanel.rez0.net /etc/mysql/debian-start[1029]: Looking for 'mariadb' as: /usr/bin/mariadb
Feb 09 09:51:24 hpanel.rez0.net /etc/mysql/debian-start[1029]: Looking for 'mariadb-check' as: /usr/bin/mariadb-check
Feb 09 09:51:24 hpanel.rez0.net /etc/mysql/debian-start[1029]: This installation of MariaDB is already upgraded to 10.6.7-MariaDB.
Feb 09 09:51:24 hpanel.rez0.net /etc/mysql/debian-start[1029]: There is no need to run mysql_upgrade again for 10.6.11-MariaDB.
Feb 09 09:51:24 hpanel.rez0.net /etc/mysql/debian-start[1029]: You can use --force if you still want to run mysql_upgrade
Feb 09 09:51:24 hpanel.rez0.net /etc/mysql/debian-start[1067]: Checking for insecure root accounts.