Mysql servicejob for mysql service failed because the control process exited with error code

How fix permanently: Job for mysql.service failed because the control process exited with error code

I am working with Ubuntu 18.04 and MySQL Server — 8.0.18

Suddenly today MySQL can’t start anymore

With the sudo service mysql status command appears:

With the sudo service mysql restart command appears:

Following and executing the two suggested commands:

• systemctl status mysql.service
• journalctl -xe

Therefore: sudo systemctl status mysql.service

And with journalctl -xe

I followed the solution about this post:

I used the innodb_force_recovery = 10 (ten), it playing, because with 1 and 2 did not work

Therefore with the sudo systemctl start mysql command is possible start the server. I can see all the data and users saved in peace.

Now through the sudo systemctl status mysql command I get

Until this point would has no sense this post, but if I do either Alpha or Beta steps:

the same problem happens again.

Therefore now is mandatory keep the innodb_force_recovery = 10 , otherwise it returns to the same problem

Warning:

The correct range is from 1 to 6, I am assuming 10 is «interpreted» how the maximum value (6)

Is there a way to configure something and remove innodb_force_recovery ? It to return to the normal or old configuration where all worked fine (without innodb_force_recovery )

Note the final content of /var/log/mysql/error.log is

I am working with VirtualBox — Ubuntu is a guest. It had been working for more of 3 months, now suddenly this situation appeared.

More Info:

One

As requested desertangels

Two

Executing cat /etc/mysql/mysql.conf.d/mysqld.cnf

Three

BTW: just in case, with mysql -u root -p appears:

Источник

MySQL not starting due to errors

I’m trying to get MySQL to work on my ubuntu server. It seems I ran into some errors and I’ve been trying to sort them out myself but I haven’t had any success. I ran:

After the installation I tried to make sure it was turned on by doing sudo service mysql start which ended up in it saying

Job for mysql.service failed because the control process exited with error code. See «systemctl status mysql.service» and «journalctl -xe» for details.

I ran sudo service mysql status Which returned this:

If someone could help with this I would appreciate it.

Here is the output of journalctl -xe after trying to start MySql:

I put it all into hastebin so the gazillion lines can actually fit into there :p

I went by the steps and during the re-install I noted these:

AppArmor parser error for /etc/apparmor.d/usr.sbin.mysqld in /etc/apparmor.d/usr.sbin.mysqld at line 9: Could not open ‘abstractions/mysql’.

E: Sub-process /usr/bin/dpkg returned an error code (1)

W: Operation was interrupted before it could finish.

Output of MySQL Install Command:

Output of sudo apt -o Dpkg::Options::=»—force-confmiss» install —reinstall mysql-server :

3 Answers 3

As described here after installing mysql-server using:

You should configure mysql:

Afterwards tests your configuration using:

If MySQL isn’t running, you can start it with sudo systemctl mysql start .

For an additional check, you can try connecting to the database using the mysqladmin tool, which is a client that lets you run administrative commands. For example, this command says to connect to MySQL as root (-u root), prompt for a password (-p), and return the version.

Firstly, you want to stop using the service structure and start getting used to systemctl structure instead

Secondly, systemd can give you some better information if you check the logging via its tool journalctl :

This should give you more information about what happened. The «status» will not necessarily tell you the events leading to the error.

The problem with starting the server was a protection by Apparmor to protect against unauthorized applications running.

This remedied by added the command line:

Other important components were ensuring against conflicts from the installed mysql-server, but purging it and reinstalling it. Ensuring the defaults are set by removing what’s failing and reinstalling what’s tested from the repository, which works.

During the process of the reinstall (in this case) there was a problem with the perl script which is part of the install routine. Fixing those problems and errors assisted in the reinstall.

The details of the issues that were causing problems were presented at to the concole of which, removing each of the issues was a step by step recovery.

Источник

mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

Ошибка запуска Job for mysql.service failed

Если у вас упала база данных MySQL и при запуске «service mysql restart» пишет такую ошибку:

Job for mysql.service failed because the control process exited with error code. See «systemctl status mysql.service» and «journalctl -xe» for details.

При выполнении команды

мы выдим такую строку:

mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

Решение проблемы mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

Добавляем в файл конфигурации /etc/mysql/my.cnf (в зависимости от вашей конфигурации my.cnf и ОС может иметь другое местоположение) строку:

Сохраняем файл my.cnf и выполняем команду:

Если это не сработало, то нужно увеличить число «innodb_force_recovery = 2» или 3, и снова запустить обновления конфигурации «sudo systemctl start mysql».

После успешного выполнения нужно закомментировать строку innodb_force_recovery и перезагрузиться (некоторые операции не разрешены в режиме принудительного восстановления).

Для более детальной консультации обращайтесь в нашу техническую поддержку, где опытные системные администраторы помогут восстановить сервер или заказывайте хостинг сайта в нашей компании уже с включенной полной поддержкой

Источник

mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

Ошибка запуска Job for mysql.service failed

Если у вас упала база данных MySQL и при запуске «service mysql restart» пишет такую ошибку:

Job for mysql.service failed because the control process exited with error code. See «systemctl status mysql.service» and «journalctl -xe» for details.

При выполнении команды

мы выдим такую строку:

mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

Решение проблемы mysql.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

Добавляем в файл конфигурации /etc/mysql/my.cnf (в зависимости от вашей конфигурации my.cnf и ОС может иметь другое местоположение) строку:

Сохраняем файл my.cnf и выполняем команду:

Если это не сработало, то нужно увеличить число «innodb_force_recovery = 2» или 3, и снова запустить обновления конфигурации «sudo systemctl start mysql».

После успешного выполнения нужно закомментировать строку innodb_force_recovery и перезагрузиться (некоторые операции не разрешены в режиме принудительного восстановления).

Для более детальной консультации обращайтесь в нашу техническую поддержку, где опытные системные администраторы помогут восстановить сервер или заказывайте хостинг сайта в нашей компании уже с включенной полной поддержкой

Источник

Failing to start mysql.service for MySQL 5.6 on Ubuntu 16.04

After following the instructions in this post on how to install MySQL 5.6 over an existing 5.7 installation on Ubuntu 16.04 I had multiple problems starting the service.

First this happened:

Which was solved by running systemctl unmask mysql.service . However then I repeatedly had this message:

Inspecting systemctl status mysql.service showed:

3 Answers 3

After Downgrading MySQL version I am also facing this try following command

The fix for this contained multiple steps including different debug logs and then following clues in those logs. I’m documenting them to help others — your problems might be different but this process should help to discover what’s wrong:

Firstly journalctl -xe contains a lot more information. In my case it contained:

This could be fixed with vi /etc/apparmor.d/usr.sbin.mysqld and adding lines for:

An interesting point is that it needs a separate line for a directory and wildcard files within it — this can be common for some unix applications but not all so might trip you up.

Once all the apparmor changes were done the system still wouldn’t start, and this time the journalctl -xe command yielded nothing useful.

I was then able to run sudo -u mysql mysqld to try starting the daemon manually. This showed a failure with InnoDB starting up, but not why.

On a whim I deleted the files /var/lib/mysql/ib_logfile* and ib_binlog and tried again; this time the server started. I was then able to terminate this and run service start mysql which worked.

Separately I deleted /var/lib/mysql/debian-5.7.flag — I am unsure if this helped or would have caused subsequent problems if I had not done so.

Hopefully this example helps somebody; please feel free to add other answers along a similar line if you encountered different problems with this process.

Источник

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

Ok. First. I tried to run a website on a server but it was too heavy for MySQL to handle. Apparently, it broke due to lack of RAM. So I changed the .cnf and .ini files for the server to lower the load, though I understand that it will work much slower.

Now I try to start the server back again.

$ sudo /etc/init.d/mysql start
[....] Starting mysql (via systemctl): mysql.serviceJob for mysql.service failed because the control p
rocess exited with error code.
See "systemctl status mysql.service" and "journalctl -xe" for details.

 failed!

For some reason it fails. I am completely out of ideas what is wrong anymore. Here are MySQL logs, what else is I need to fix?

2019-01-31T02:10:13.714141Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-01-31T02:10:13.716372Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.25-0ubuntu0.18.10.2) starting as process 24740 ...
2019-01-31T02:10:13.720956Z 0 [Note] InnoDB: PUNCH HOLE support available
2019-01-31T02:10:13.720991Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-01-31T02:10:13.720995Z 0 [Note] InnoDB: Uses event mutexes
2019-01-31T02:10:13.720999Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-01-31T02:10:13.721002Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2019-01-31T02:10:13.721005Z 0 [Note] InnoDB: Using Linux native AIO
2019-01-31T02:10:13.721292Z 0 [Note] InnoDB: Number of pools: 1
2019-01-31T02:10:13.721420Z 0 [Note] InnoDB: Using CPU crc32 instructions
2019-01-31T02:10:13.725482Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2019-01-31T02:10:13.725537Z 0 [ERROR] InnoDB: mmap(137428992 bytes) failed; errno 12
2019-01-31T02:10:13.725544Z 0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2019-01-31T02:10:13.725548Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2019-01-31T02:10:13.725558Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2019-01-31T02:10:13.725563Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2019-01-31T02:10:13.725568Z 0 [ERROR] Failed to initialize builtin plugins.
2019-01-31T02:10:13.725571Z 0 [ERROR] Aborting
2019-01-31T02:10:13.728065Z 0 [Note] Binlog end
2019-01-31T02:10:13.728148Z 0 [Note] Shutting down plugin 'CSV'
2019-01-31T02:10:13.728458Z 0 [Note] /usr/sbin/mysqld: Shutdown complete

/etc/mysql/mysql.conf.d/mysqld.cnf file:

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
# Here is entries for some specific programs
# The following values assume you have at least 32M ram
[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0
[mysqld]
#
# * Basic Settings
#
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address            = 127.0.0.1
#
# * Fine Tuning
#
key_buffer_size         = 16M
sort_buffer_size        = 16M
read_buffer_size        = 1M
write_buffer_size       = 1M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover-options  = BACKUP
max_connections         = 5
table_open_cache        = 32
thread_concurrency      = 6
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M
#
#thanks https://forums.cpanel.net/threads/optimizing-mysql-for-512mb-80-of-installed-ram.170278/
#
table_cache = 256
myisam_sort_buffer_size = 16M
thread_cache_size = 8
wait_timeout = 60
connect_timeout = 30
interactive-timeout = 50
query-cache-type = 1
query_cache_size = 8M
query_cache_limit = 1M
max_user_connections = 5
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#slow_query_log         = 1
#slow_query_log_file    = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id              = 1
#log_bin                        = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size   = 100M
#binlog_do_db           = include_database_name
#binlog_ignore_db       = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#

i feel like i broke everything…