hi , i move my server from location A, 4 years working normally, to a new place , call it Location B, a new place with sema isp company, and a new IP, we move server from A to B, change Ip definition on domain provider , and magic, Nothing work! console is not open ( blank page) , and all web site give "Error establishing a database connection". w/o to handle o modify server. Now we reinstall server in Location A, and , magic, the same behavior!, how is it posible ? what is the defect? i apreciate your guide please!
There are many things that may not be correct. First of all you should provide some basic Information as described in the "Read before Posting". What OS Version do you use? Which ISPConfig Version? Is the database service even running?
So this is a single server? If otherwise things are the same, only IP -number changes, find the places where that is to be changed with command Code: grep -r write.your.ip.here /etc/ Then it was somewhere in ISPConfig panel system setting, where IP number is entered.
sorry, it is my frustation ubuntu 18.04 ispconfig 3.xx i dont remember i dont make the last update, y now i have no access its a single server th internal ip (intranet) i dont need to change mariadb give failed, but i donw understand, we dont change, edit o copy anything, just shutdown and power up in the new locatio n
At least provide us some log information of the service then? Code: systemctl status mariadb Code: journalctl -u mariadb
maria db give ● mariadb.service - MariaDB 10.1.48 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: Active: failed (Result: exit-code) since Wed 2022-11-02 16:02:40 CET; 11min a Docs: man:mysqld(8) https://mariadb.com/kb/en/library/systemd/ Process: 1501 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WS Process: 1323 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR Process: 1275 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START Process: 1154 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/ru Main PID: 1501 (code=exited, status=1/FAILURE) Status: "MariaDB server is down" nov 02 16:02:32 mnsvr systemd[1]: Starting MariaDB 10.1.48 database server... nov 02 16:02:34 mnsvr mysqld[1501]: 2022-11-02 16:02:34 140526823013504 [Note] / nov 02 16:02:40 mnsvr systemd[1]: mariadb.service: Main process exited, code=exi nov 02 16:02:40 mnsvr systemd[1]: mariadb.service: Failed with result 'exit-code nov 02 16:02:40 mnsvr systemd[1]: Failed to start MariaDB 10.1.48 database serve lines 1-17/17 (END)...skipping... ● mariadb.service - MariaDB 10.1.48 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2022-11-02 16:02:40 CET; 11min ago Docs: man:mysqld(8) https://mariadb.com/kb/en/library/systemd/ Process: 1501 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE) Process: 1323 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_STA Process: 1275 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Process: 1154 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS) Main PID: 1501 (code=exited, status=1/FAILURE) Status: "MariaDB server is down" nov 02 16:02:32 mnsvr systemd[1]: Starting MariaDB 10.1.48 database server... nov 02 16:02:34 mnsvr mysqld[1501]: 2022-11-02 16:02:34 140526823013504 [Note] /usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0ubuntu0.18.04.1) starting as process 1501 ... nov 02 16:02:40 mnsvr systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE nov 02 16:02:40 mnsvr systemd[1]: mariadb.service: Failed with result 'exit-code'. nov 02 16:02:40 mnsvr systemd[1]: Failed to start MariaDB 10.1.48 database server.
and with second command [1]+ Detenido systemctl status mariadb root@mnsvr:~# journalctl -u mariadb -- Logs begin at Sat 2020-04-04 20:52:04 CEST, end at Wed 2022-11-02 16:17:21 CET. -- nov 02 10:25:58 mnsvr systemd[1]: Stopping MariaDB 10.1.48 database server... nov 02 10:26:02 mnsvr systemd[1]: Stopped MariaDB 10.1.48 database server. -- Reboot -- nov 02 11:02:10 mnsvr systemd[1]: Starting MariaDB 10.1.48 database server... nov 02 11:02:12 mnsvr mysqld[1354]: 2022-11-02 11:02:12 140055355239552 [Note] /usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0ubuntu0.18.04.1) starting as process 1354 ... nov 02 11:02:16 mnsvr systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE nov 02 11:02:16 mnsvr systemd[1]: mariadb.service: Failed with result 'exit-code'. nov 02 11:02:16 mnsvr systemd[1]: Failed to start MariaDB 10.1.48 database server. -- Reboot -- nov 02 13:30:54 mnsvr systemd[1]: Starting MariaDB 10.1.48 database server... nov 02 13:30:55 mnsvr mysqld[1412]: 2022-11-02 13:30:55 140582691712128 [Note] /usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0ubuntu0.18.04.1) starting as process 1412 ... nov 02 13:31:00 mnsvr systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE nov 02 13:31:00 mnsvr systemd[1]: mariadb.service: Failed with result 'exit-code'. nov 02 13:31:00 mnsvr systemd[1]: Failed to start MariaDB 10.1.48 database server. -- Reboot -- nov 02 13:34:20 mnsvr systemd[1]: Starting MariaDB 10.1.48 database server... nov 02 13:34:21 mnsvr mysqld[1330]: 2022-11-02 13:34:21 140210221350016 [Note] /usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0ubuntu0.18.04.1) starting as process 1330 ... nov 02 13:34:26 mnsvr systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE nov 02 13:34:26 mnsvr systemd[1]: mariadb.service: Failed with result 'exit-code'. nov 02 13:34:26 mnsvr systemd[1]: Failed to start MariaDB 10.1.48 database server. -- Reboot -- nov 02 13:35:01 mnsvr systemd[1]: Starting MariaDB 10.1.48 database server... nov 02 13:35:02 mnsvr mysqld[1400]: 2022-11-02 13:35:02 140082955353216 [Note] /usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0ubuntu0.18.04.1) starting as process 1400 ... nov 02 13:35:06 mnsvr systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE nov 02 13:35:06 mnsvr systemd[1]: mariadb.service: Failed with result 'exit-code'. nov 02 13:35:06 mnsvr systemd[1]: Failed to start MariaDB 10.1.48 database server. -- Reboot -- nov 02 15:25:01 mnsvr systemd[1]: Starting MariaDB 10.1.48 database server... nov 02 15:25:02 mnsvr mysqld[1383]: 2022-11-02 15:25:02 140306595241088 [Note] /usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0ubuntu0.18.04.1) starting as process 1383 ... nov 02 15:25:07 mnsvr systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE nov 02 15:25:07 mnsvr systemd[1]: mariadb.service: Failed with result 'exit-code'. nov 02 15:25:07 mnsvr systemd[1]: Failed to start MariaDB 10.1.48 database server. -- Reboot -- nov 02 16:02:32 mnsvr systemd[1]: Starting MariaDB 10.1.48 database server... nov 02 16:02:34 mnsvr mysqld[1501]: 2022-11-02 16:02:34 140526823013504 [Note] /usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0ubuntu0.18.04.1) starting as process 1501 ... nov 02 16:02:40 mnsvr systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE nov 02 16:02:40 mnsvr systemd[1]: mariadb.service: Failed with result 'exit-code'. nov 02 16:02:40 mnsvr systemd[1]: Failed to start MariaDB 10.1.48 database server.
Ok we need the error log to see what is going on here. You can check if there is a error.log set see: Code: mysqld --help --verbose | grep 'log-error' | tail -1 This will either output "log-error /var/log/...." or "log-error ", if there is no file specified after log-error it is not set. You can add the following line to the mariadb config to enable error logging: Code: log_error=/var/log/mysql/mariadb.err After that restart the service and post the output of /var/log/mysql/mariadb.err
it give this result: 2022-11-02 16:24:58 140083456711808 [Note] Plugin 'FEEDBACK' is disabled. log-error /var/log/mysql/error.log 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB. 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: Using mutexes to ref count buffer pool pages 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: The InnoDB memory heap is disabled 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: Compressed tables use zlib 1.2.11 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: Using Linux native AIO 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: Using SSE crc32 instructions 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: Initializing buffer pool, size = 128.0M 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: Completed initialization of buffer pool 2022-11-02 16:02:34 140526823013504 [Note] InnoDB: Highest supported file format is Barracuda. 2022-11-02 16:02:36 140526823013504 [Note] InnoDB: 128 rollback segment(s) are active. 2022-11-02 16:02:36 140526823013504 [Note] InnoDB: Waiting for purge to start 2022-11-02 16:02:36 140526823013504 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 245664715660 2022-11-02 16:02:37 140526823013504 [Note] Plugin 'FEEDBACK' is disabled. 2022-11-02 16:02:37 140526823013504 [Note] Recovering after a crash using tc.log 2022-11-02 16:02:37 140526823013504 [ERROR] Can't init tc log 2022-11-02 16:02:37 140526823013504 [ERROR] Aborting 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB. 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: Using mutexes to ref count buffer pool pages 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: The InnoDB memory heap is disabled 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: Compressed tables use zlib 1.2.11 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: Using Linux native AIO 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: Using SSE crc32 instructions 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: Initializing buffer pool, size = 128.0M 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: Completed initialization of buffer pool 2022-11-02 16:18:52 140168479743104 [Note] InnoDB: Highest supported file format is Barracuda. 2022-11-02 16:18:53 140168479743104 [Note] InnoDB: 128 rollback segment(s) are active. 2022-11-02 16:18:53 140168479743104 [Note] InnoDB: Waiting for purge to start 2022-11-02 16:18:53 140168479743104 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 245664715670 2022-11-02 16:18:53 140168479743104 [Note] Plugin 'FEEDBACK' is disabled. 2022-11-02 16:18:53 140167805400832 [Note] InnoDB: Dumping buffer pool(s) not yet started 2022-11-02 16:18:53 140168479743104 [Note] Recovering after a crash using tc.log 2022-11-02 16:18:53 140168479743104 [ERROR] Can't init tc log 2022-11-02 16:18:53 140168479743104 [ERROR] Aborting
So there is the issue. I don't know where tc.log is located so: Code: find / -iname "tc.log" Then move the tc.log to another place and try again: Code: mv tc.log ~/tc.log.backup systemctl restart mariadb
i move from a diferebt place , and voila! why is the reason ? why is change only we plug server in a diferent place?
This can happen when the filesystem runs out of space, forced shutdowns or crashes of the service. The transaction log file corrupts in some cases and when the service trys to read it fails and errors
do you say that my problem when i moving was casuality? how can i check or prevent this behavior (out of space)?
I don't know if the moving was the cause. Things you can do however: - Don't force shutdown a system; neither with a command nor with just unplugging power/force power off the VM - Monitor your disk space with a monitoring/alert solution - Monitor services and logs - manually check the system and logs once i a while - keep the system up to date
well, i search and check everything , and finally i found it : disk full ( it seem stupid, but is true). casuallity was the moveing.tx a lot a question: how do you find the resposability of this problem? ( i like to lern your debug process) tx a lot again
I'm in the FOSS space for more than 10 years now, started at an age of 15, and work as a linux sysadmin for over 5 years now You learn to know your systems and where to look when things don't work. A *nix system is quiet lovly when it comes to debugging, there are alot of logs and they are usually very precise. After a long time you either no the problem, because you encountered it before, or you know what to check. And in the case that dosen't resolve the problem you start to check for the classics like desribed in the other post or ask for help at howtoforge You can't know everything and sometimes we are just blind Anyways a simple problem like run out of disk space can be avoided by a monitoring solution
and one of those monitoring solutions is monit. @Th0m has written a script that'll install it and have most, if not all, of the required configuration in place to monitor a typical ispconfig server: https://forum.howtoforge.com/thread...11-and-ubuntu-20-04-server.89482/#post-439002
I don't use that script but I do rely on monit a lot to monitor and maintain mine automatically and so far it has proven itself very useful to me.
