Kopano service not starting

After update to the new kopano version in the app center the kopano-server service not starting.

Error interactive authentication requiered.

Waht can I do?

best regards

Chris

Is that the error you are getting? Where is it logged?

Please provide more information about your environment. https://wiki.z-hub.io/display/K4U/Debugging+Kopano+on+Univention could give you an indication where to get these information.

Hi,
thanks for your answer.

I had check the problem.

When the UCS server starts the MariaDB database server couldn’t start automaticaly.

When I start the mysql service and kopano-server serices maually it works.

Why not automaticaly?

Do you need any informations of me to fix that problem?

best regards

Chris

I already provided you with a link on which information to provide.

A not starting database has in the past been discussed in Kopano won't start after upgrade to 4.2. I would recommend to figure out why the database did not start on boot (the linked post gives some commands for that as well).

Hi,

I’m sorry, but I’m new to work with UCS and Kopano.

Here is the result of the versions

ii kopano-server-packages 8.6.2.1-0+5.1
ii kopano-webapp 3.4.21.1723+78.1
ii kopano-webapp-plugin-desktopnotifications 2.0.1.6+16.1
ii kopano-webapp-plugin-filepreviewer 2.0.0.15+11.1
ii kopano-webapp-plugin-files 2.1.4.293+80.1
ii kopano-webapp-plugin-filesbackend-owncloud 2.1.0.84+35.1
ii kopano-webapp-plugin-filesbackend-smb 2.1.0.48+28.1
ii kopano-webapp-plugin-folderwidgets 3.4.21.1723+78.1
ii kopano-webapp-plugin-mdm 2.1.0.97+33.1
ii kopano-webapp-plugin-smime 2.2.0.171+19.1
ii kopano-webapp-plugin-spell 2.0.0.17+34.1
ii kopano-webapp-plugin-spell-de-de 2.0.0.3+22.1
ii kopano-webapp-plugin-spell-en 2.0.0.1+22.1
ii kopano-webapp-plugin-spell-nl 2.0.0.1+23.1
ii kopano-webapp-plugin-titlecounter 3.4.21.1723+78.1
ii kopano-webapp-plugin-webappmanual 3.4.21.1723+78.1
ii kopano4ucs 1.5.5
ii kopano4ucs-lib 1.5.5
ii kopano4ucs-schema 1.5.5
ii kopano4ucs-udm 1.5.5
ii kopano4ucs-webapp 1.4.18
ii kopano4ucs-z-push 1.4.18
ii z-push-kopano 2.4.4+0-0
ii z-push-kopano-gabsync 2.4.4+0-0

univention-app info
UCS: 4.3-2 errata313
Installed: cups=2.2.1 dhcp-server=12.0 fetchmail=6.3.26 kde=5.8 kopano-core=8.6.2.1-2 kopano-webapp=3.4.21.1723 samba4=4.7 z-push-kopano=2.4.4

I don’t find the server.log in /var/log/kopano

Why not?

From what you have said so far your problems come more from systemd, than either UCS or Kopano, so that should be no problem.

It says the following on the page I linked you to:

By default new installations log to journald. You can view the individual logfiles by executing, e.g.:

# for kopano-server
journalctl -u kopano-server

This is the log of this morning, when I had restarted the server

 systemd[1]: Started Kopano Core Storage Server.
Nov 20 09:46:45 ucs01 kopano-server[4692]: Tue Nov 20 09:46:45 2018: [=======] Starting kopano-server version 8.6.2 (pid 4692)
Nov 20 09:46:45 ucs01 kopano-server[4692]: Tue Nov 20 09:46:45 2018: [error  ] Coredumps will not be generated: kopano-server requires the fs.suid_dumpable
Nov 20 09:46:45 ucs01 kopano-server[4692]: Tue Nov 20 09:46:45 2018: [error  ] KDatabase::Connect(): database access error Unknown error code (0x80000007),
Nov 20 09:46:45 ucs01 kopano-server[4692]: Tue Nov 20 09:46:45 2018: [crit   ] Unable to connect to database: MYSQL not initialized
Nov 20 09:46:45 ucs01 kopano-server[4692]: An error occurred (80000007). Please check logfile "-" for details.
Nov 20 09:46:45 ucs01 kopano-server[4692]: Tue Nov 20 09:46:45 2018: [=======] Server shutdown complete.
Nov 20 09:46:45 ucs01 systemd[1]: kopano-server.service: Main process exited, code=exited, status=255/n/a
Nov 20 09:46:45 ucs01 systemd[1]: kopano-server.service: Unit entered failed state.
Nov 20 09:46:45 ucs01 systemd[1]: kopano-server.service: Failed with result 'exit-code'.

You now have established that kopano-server could not start, since he was unable to connect to the database. The next step would be why the database is not up. e.g. with systemctl status mariadb.service and journalctl -u mariadb.service.

Thanks, here is the result

 systemctl status mariadb.service
● mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-11-20 09:47:33 CET; 1 day 22h ago
  Process: 4904 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 4901 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
  Process: 4761 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-envi
  Process: 4757 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 4754 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 4873 (mysqld)
   Status: "Taking your SQL requests now..."
    Tasks: 41 (limit: 4915)
   Memory: 150.9M
      CPU: 4min 4.606s
   CGroup: /system.slice/mariadb.service
           └─4873 /usr/sbin/mysqld

Nov 20 09:47:29 ucs01 systemd[1]: Starting MariaDB database server...
Nov 20 09:47:29 ucs01 mysqld[4873]: 2018-11-20  9:47:29 139685060604480 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 4873
Nov 20 09:47:33 ucs01 systemd[1]: Started MariaDB database server.
Nov 19 17:27:08 ucs01 systemd[1]: Starting MariaDB database server...
Nov 19 17:27:27 ucs01 mysqld[1241]: 2018-11-19 17:27:27 139713495630400 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 1241
Nov 19 17:28:49 ucs01 systemd[1]: mariadb.service: Start operation timed out. Terminating.
Nov 19 17:28:57 ucs01 systemd[1]: Failed to start MariaDB database server.
Nov 19 17:28:57 ucs01 systemd[1]: mariadb.service: Unit entered failed state.
Nov 19 17:28:57 ucs01 systemd[1]: mariadb.service: Failed with result 'timeout'.
Nov 20 09:47:29 ucs01 systemd[1]: Starting MariaDB database server...
Nov 20 09:47:29 ucs01 mysqld[4873]: 2018-11-20  9:47:29 139685060604480 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 4873
Nov 20 09:47:33 ucs01 systemd[1]: Started MariaDB database server.

I don’t find why the DB couldn’t start (Timeout) within the boot process but when I start the process manually it starts.

Ok, then I am again mentioning Kopano won't start after upgrade to 4.2, which will give you more hints on debugging this.

I can confirm the MariaDB timeout problem at boot. Same thing on my UCS system. Too many apps (mainly because of docker) are starting in parallel, the HDD can’t keep up and MariaDB can’t start.
After a manual start of MariaDB and a manual restart of kopano-server solves the problem until the next reboot.

@Schmidtch @Emilfelix

could you try the following? We cannot formally depend on mysql/mariadb in our systemd units, since at other installation this service could be running on a different hosts. For UCS systems this should not be the case (at least in 99,99999999999 of the cases).

Can you create a systemd override to see if that solves it for you. you have to do the following:

# first create the override file by calling
systemctl edit kopano-server
# this will open up an editor where you have to paste the following (and save the file afterwards):
[Unit]
After=mariadb.service

Once this is done kopano-server should always wait for mariadb to be started.

If that fixes/improves it for you then https://stash.z-hub.io/projects/K4U/repos/kopano4ucs/pull-requests/21/overview could be merged and be part of the next app update.

Hi @fbartels,

tried it right now. Nice approach but my MariaDB is still crashing at boot.
My virtual HDD is not the fastest but there is just too much stuff getting executed in parallel at boot, eg. the start of all docker containers, apt-get stuff (according to top) etc…

In fact, I have to wait until every DB dependent process crashed, then restart MariaDB and restart all crashed services (Kopano, BlueSpice, OpenProject, Wordpress) after another.

Regards,
Felix

ok, it its indeed mariadb causing the chain to fail, then there is nothing we can do in Kopano about it.

There is a request to fix one possible issue (hardcoded timeout in mariadb initscript) in UCS

Hi together,

I want to inform you, that after the update to kopano core version 8.6.8.2 the MariaDB and kopano-server service are starts now after a reboot of the server.

Thanks all of you for your help.

best regards

Mastodon