Изпечатай

[neter]

Ахааа, спира те AppArmor Отвори файла /etc/apparmor.d/usr.sbin.mysqld и замени навсякъде "/var/lib/mysql" с новата папка "/home/mysql".

[backinblack]

Това е редактирания:

# vim:syntax=apparmor
# Last Modified: Tue Jun 19 17:37:30 2007
#include <tunables/global>

/usr/sbin/mysqld {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>
  #include <abstractions/mysql>
  #include <abstractions/winbind>

  capability dac_override,
  capability sys_resource,
  capability setgid,
  capability setuid,

  network tcp,

  /etc/hosts.allow r,
  /etc/hosts.deny r,

  /etc/mysql/*.pem r,
  /etc/mysql/conf.d/ r,
  /etc/mysql/conf.d/* r,
  /etc/mysql/my.cnf r,
  /usr/sbin/mysqld mr,
  /usr/share/mysql/** r,
  /var/log/mysql.log rw,
  /var/log/mysql.err rw,
  /home/mysql/ r,
  /home/mysql/** rwk,
  /var/log/mysql/ r,
  /var/log/mysql/* rw,
  /var/run/mysqld/mysqld.pid w,
  /var/run/mysqld/mysqld.sock w,

  /sys/devices/system/cpu/ r,
}

А това е не редактирания:

# vim:syntax=apparmor
# Last Modified: Tue Jun 19 17:37:30 2007
#include <tunables/global>

/usr/sbin/mysqld {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>
  #include <abstractions/mysql>
  #include <abstractions/winbind>

  capability dac_override,
  capability sys_resource,
  capability setgid,
  capability setuid,

  network tcp,

  /etc/hosts.allow r,
  /etc/hosts.deny r,

  /etc/mysql/*.pem r,
  /etc/mysql/conf.d/ r,
  /etc/mysql/conf.d/* r,
  /etc/mysql/my.cnf r,
  /usr/sbin/mysqld mr,
  /usr/share/mysql/** r,
  /var/log/mysql.log rw,
  /var/log/mysql.err rw,
  /var/lib/mysql/ r,
  /var/lib/mysql/** rwk,
  /var/log/mysql/ r,
  /var/log/mysql/* rw,
  /var/run/mysqld/mysqld.pid w,
  /var/run/mysqld/mysqld.sock w,

  /sys/devices/system/cpu/ r,
}

И пак не стартира!

Тона долу е syslog

Nov 23 15:54:13 bonchodesktop1004i386 init: mysql main process ended, respawning
Nov 23 15:54:43 bonchodesktop1004i386 init: mysql post-start process (3826) terminated with status 1
Nov 23 15:54:43 bonchodesktop1004i386 kernel: [  487.905087] type=1400 audit(1322056483.591:37): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3898 comm="apparmor_parser"
Nov 23 15:54:43 bonchodesktop1004i386 init: mysql main process (3902) terminated with status 1
Nov 23 15:54:43 bonchodesktop1004i386 init: mysql main process ended, respawning
Nov 23 15:55:13 bonchodesktop1004i386 init: mysql post-start process (3904) terminated with status 1
Nov 23 15:55:13 bonchodesktop1004i386 kernel: [  518.068416] type=1400 audit(1322056513.771:38): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3979 comm="apparmor_parser"
Nov 23 15:55:13 bonchodesktop1004i386 init: mysql main process (3983) terminated with status 1
Nov 23 15:55:13 bonchodesktop1004i386 init: mysql main process ended, respawning

А това messages

Nov 23 15:48:49 bonchodesktop1004i386 sudo: pam_sm_authenticate: Called
Nov 23 15:48:49 bonchodesktop1004i386 sudo: pam_sm_authenticate: username = [boncho]
Nov 23 15:49:11 bonchodesktop1004i386 kernel: [  156.214027] type=1400 audit(1322056151.683:26): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3011 comm="apparmor_parser"
Nov 23 15:49:41 bonchodesktop1004i386 kernel: [  186.371132] type=1400 audit(1322056181.863:27): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3085 comm="apparmor_parser"
Nov 23 15:50:12 bonchodesktop1004i386 kernel: [  216.530839] type=1400 audit(1322056212.043:28): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3169 comm="apparmor_parser"
Nov 23 15:50:42 bonchodesktop1004i386 kernel: [  246.693030] type=1400 audit(1322056242.223:29): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3255 comm="apparmor_parser"
Nov 23 15:51:12 bonchodesktop1004i386 kernel: [  276.839003] type=1400 audit(1322056272.391:30): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3329 comm="apparmor_parser"
Nov 23 15:51:42 bonchodesktop1004i386 kernel: [  306.989726] type=1400 audit(1322056302.559:31): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3406 comm="apparmor_parser"
Nov 23 15:52:12 bonchodesktop1004i386 kernel: [  337.139917] type=1400 audit(1322056332.727:32): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3520 comm="apparmor_parser"
Nov 23 15:52:42 bonchodesktop1004i386 kernel: [  367.292118] type=1400 audit(1322056362.900:33): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3596 comm="apparmor_parser"
Nov 23 15:53:13 bonchodesktop1004i386 kernel: [  397.448434] type=1400 audit(1322056393.076:34): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3670 comm="apparmor_parser"
Nov 23 15:53:43 bonchodesktop1004i386 kernel: [  427.600926] type=1400 audit(1322056423.248:35): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3745 comm="apparmor_parser"
Nov 23 15:54:13 bonchodesktop1004i386 kernel: [  457.744493] type=1400 audit(1322056453.412:36): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3820 comm="apparmor_parser"
Nov 23 15:54:43 bonchodesktop1004i386 kernel: [  487.905087] type=1400 audit(1322056483.591:37): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3898 comm="apparmor_parser"
Nov 23 15:55:13 bonchodesktop1004i386 kernel: [  518.068416] type=1400 audit(1322056513.771:38): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=3979 comm="apparmor_parser"
Nov 23 15:55:43 bonchodesktop1004i386 kernel: [  548.227713] type=1400 audit(1322056543.951:39): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=4074 comm="apparmor_parser"
Nov 23 15:56:14 bonchodesktop1004i386 kernel: [  578.378578] type=1400 audit(1322056574.119:40): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=4150 comm="apparmor_parser"
Nov 23 15:56:44 bonchodesktop1004i386 kernel: [  608.538330] type=1400 audit(1322056604.299:41): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=4225 comm="apparmor_parser"
Nov 23 15:57:14 bonchodesktop1004i386 kernel: [  638.688305] type=1400 audit(1322056634.468:42): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=4341 comm="apparmor_parser"
Nov 23 15:57:44 bonchodesktop1004i386 kernel: [  668.846321] type=1400 audit(1322056664.648:43): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=4422 comm="apparmor_parser"
Nov 23 15:58:14 bonchodesktop1004i386 kernel: [  699.005152] type=1400 audit(1322056694.824:44): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=4504 comm="apparmor_parser"
Nov 23 15:58:45 bonchodesktop1004i386 kernel: [  729.166390] type=1400 audit(1322056725.008:45): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=4580 comm="apparmor_parser"

[neter]

Сега логът от AppArmor изглежда добре, и явно има нещо друго, което също пречи. Все пак спри AppArmor и тогава пробвай пак да пуснеш MySQL сървъра, за да сме сигурни, че наистина не е останала причина в AppArmor. А преди промяната на папката работел ли е този сървър?

[backinblack]

Да, работеше с демо база магазин на микроинвест складовата програма. Само един юзер има, този който си е по подразбиране root с елементарна парола от 11111.
На сървъра никакви настройки не са правени, освен парола при инсталирането му от хранилището си на Убунту 10.04.
Всичко правя само с графични инструменти и идея си нямам как да го спра този процес! Не го виждам и в таск менажера.

[radoulov]

Може ли да видим какво има в:

Код:

/var/log/mysql/error.log

?

Ако си направил само cp -r (не mv или cp -pr) с root, ще трябва да направиш и:

Код:

chown -R mysql:mysql /home/mysql

[backinblack]

11124 11:13:54 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
111124 11:13:54 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
111124 11:13:54  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.
111124 11:14:24 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
111124 11:14:24 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
111124 11:14:24  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.
111124 11:14:54 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
111124 11:14:54 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
111124 11:14:54  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.
111124 11:15:24 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
111124 11:15:24 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
111124 11:15:24  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.

[radoulov]

Код:

InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.

Даде ли права с chown -R?

[backinblack]

След изпълнение на командата

chown -R mysql:mysql /home/mysql

Сървъра стартира и програмата се връзва с базата!

Много благодарство и на двамата! Сега ще върна снапшота на виртуалката до предишно положение за да го направя отново и ще обобщя стъпките

[backinblack]

След копирането на папката с файл менажера и промяната на директорията с Уебмин,
редактиране на файла usr.sbin.mysqld по начина описан по-горе и изпълнение на командата sudo chown -R mysql:mysql /home/mysql , сървара стартира и работи с новата директория на базите.

[borovaka]

//off-topic
@backinblack А защо ти трябваше да го правиш? В смисъл /home ти е отделен дял или просто реши да пробваш?

[backinblack]

//off-topic
@backinblack А защо ти трябваше да го правиш? В смисъл /home ти е отделен дял или просто реши да пробваш?

Home e отделен партишън, но са два диска в софтуерен райд 1. Като е в райд, не става номера с лайв сд да си извадя инфото преди да преинсталирам, но мога върху софтуерния райд да преинсталирам със запазване на инфото в хоме и после след стартиране на системата да си правиш каквото искаш.
Това е за в случай, че се омаже нещо и не запали след рестарт, а не при дефектиране на диск!
Другата причина е, че дисковете не са много големи, по 80ГБ са и по-рационално да се използва мястото. Сега съм го направил 5ГБ роот, към 1ГБ суап и другото хоме и с инсталирано всичко което му е нужно в роот остават около 1,5ГБ празно "да диша системата", а базата при мястото за файлов сървър където може да се варира лесно в случай, че вземе да се ползва много и порасне много на обем.

[neter]

Home e отделен партишън, но са два диска в софтуерен райд 1. Като е в райд, не става номера с лайв сд да си извадя инфото преди да преинсталирам...

Опа, я помисли пак по въпроса Това е RAID 1 - масив, при който двата диска съдържат една и съща информация, с цел, ако единият се сгъбяса, другият да продължава да предоставя всички данни, които преди това са били налични в масива. Когато единият диск падне, масивът се разпада, но всичката информация продължава да е налична на другия диск. Няма никакъв проблем да извадиш диска от така или иначе разпадналия се масив и да го сложиш да си работи самостоятелно, все едно никога не е бил в масив, тъй като всичката информация си е налична.
Ако масивът текущо си е добре и заредиш система от LiveCD, понеже масивът е софтуерен, ако не вържеш отново двата диска, системата от LiveCD-то ще ги вижда като два отделни диска, съдържащи една и съща информация. Каква е разликата в единия диск (който в предната ситуация е бил здравият диск в разпадналия се масив, а сега е един от двата идентични диска) и в данните върху него, че да не можеш да ги вземеш директно и веднага чрез LiveCD-то без да ги слагаш в масив?

П.П.: За да бъдем по-точни, има една част от информацията, която може и да не е налична и на двата диска, и това е информацията в MBR сектора. По подразбиране софтуерният RAID 1 не пълни MBR-то и на двата диска, така че, ако на този масив ти е системата, ползваш MBR за bootloader-a (не е препоръчително за масив, по-добре ползвай /boot) и не си си изравнил MBR-тата на двата диска след вдигането на масива (например с dd), то ако ти се бъгне дискът, върху който са ти записите за bootloader-а, ще останеш без bootloader за другия диск, и системата няма да тръгне, докато не му осигуриш такъв. Но... в случая не става дума за този случай.

[backinblack]

При тестовете ми на хардуера, сега както е направено, като изключа единия диск(от сата буксата) и системата си стартира само от единия диск, но като зареди от лайв сд, не е като когато не в райд, не могя с файловия менажер да отворя папките на диска.
Като си включа пак изключения диск, с уебмина си ребилдва и всичко си е ток и жица. След ребилдването, изключвам другия и си стартира пак без проблеми. Като измъкна буксата при работеща система, всичко замръзва, но след изключване от бъстър копчето си зарежда. Експериментирах си как ще се държи райда при евентоално дефектиране на диск, но това е при нагласена и добре работеща система, но в случай, че аз или някой друг омаже нещо и не може да стартира, със лайв сд или с parted mages не се отварят папките на дисковете като са в софтуерен райд.

[neter]

Или не си го монтирал правилно в LiveCD-то, или нещо пак си имал с правата на потребителя... някоя такава подробност ще да си пропуснал, като с т.4 от стъпките за дебъгването на MySQL-а ти

[backinblack]

Ами незнам! От малко повече от година съм на линукс и карам по уиндоуски, само с графични инструменти и не съм имал такива проблеми с дискове които не са в райд, но пък по този начин много по-рационално ще се използва мястото на харда. Няма да има нужда да оставям прекалено много място за mysql-а в роот директорията, та като расте да има място и през това време да не може да се ползва за друго.