Atualização 1:
Acabei de dar uma camada extra de testes, escrevendo um script de shell (.sh, #! / bin / bash) e um script php para ser executado pelo cli do php.
Bash funciona.
Parece que não é o contexto HTTP do Apache, mas o próprio PHP está causando os problemas. Porque um simples php raider.php executado a partir do shell do root tem os mesmos 2 problemas mencionados originalmente.
Estou criando um appliance que tenha um WebOS no topo. O WebOS está sendo hospedado com o Apache sendo executado como http:http . Como o WebOS precisa de acesso ao sistema operacional (raiz), os sudoers são configurados - para permitir http ALL com NOPASSWD.
Por favor, não informe sobre os processos que estão sendo executados como root - o ambiente é controlado e está funcionando há 2 anos com mais de 40 unidades vendidas e sem problemas relatados.
Os comandos são executados por php (mod_php5 para Apache) com proc_open de um contexto de solicitação HTTP.
Todo comando parece estar funcionando bem, exceto por mdadm --create . Quando tento criar um array, há resultados aleatórios dependendo do nível do RAID que escolhi fazer.
Anteriormente, eu tive um , mas isso não é mais o caso. O problema começou a aparecer depois de algumas atualizações do sistema operacional (não sei quando exatamente, esta é a versão antiga do WebOS que não está funcionando e teve que ser trazida até recentemente e, aparentemente, precisa ser corrigido - há também uma nova versão que funciona bem (tem um ciclo de execução de comando diferente)).
Estou usando o gancho mdadm_udev initramfs para montar o RAID ao iniciar. Deixei /etc/mdadm.conf empty, porque mdadm_udev parece montar o RAID corretamente com base em seus metadados. O único problema, no entanto, é que quando ele é montado, ele nomeia o ataque com base em <hostname>:<raidname> .
Devido à captura acima, estou usando mdadm --create /dev/md/<hostname>:stoneshare ... , que parece estar rodando bem na CLI, não importa qual seja o usuário (usuários não-root são executados como sudo e bem sucedidos), os problemas surgem quando executados através do contexto HTTP.
Cenário nº 1, RAID0:
<?php
$command = sprintf('sudo mdadm --create /dev/md/%s:stoneshare --level 0 --raid-devices 2 /dev/sdb1 /dev/sdc1');
proc_open($command, /* ... */, /* ... */);
O RAID é criado, mas, onde a CLI faz o RAID em /dev/md127 e os links simbólicos para /dev/md/<hostname>:<sharename> , executando o script acima, acabo com /dev/md127 sem link:
[root@stone ~]# mdadm --detail --scan
ARRAY /dev/md127 metadata=1.2 name=stone:stoneshare UUID=7329e458:96be442a:84f616d8:fd4ba42e
[root@stone ~]# ls -la /dev/md*
brw-rw---- 1 root disk 9, 127 Jul 30 11:48 /dev/md127
Cenário nº 2, RAID1:
<?php
$command = sprintf('sudo mdadm --create /dev/md/%s:stoneshare --level 1 --assume-clean --raid-devices 2 /dev/sdb1 /dev/sdc1');
proc_open($command, /* ... */, /* ... */);
Verifique:
[root@stone ~]# mdadm --detail --scan
ARRAY /dev/md/stone:stoneshare metadata=1.2 name=stone:stoneshare UUID=7329e458:96be442a:84f616d8:fd4ba42e
[root@stone ~]# ls -la /dev/md*
brw-rw---- 1 root disk 9, 127 Jul 30 11:48 /dev/md127
/dev/md:
total 0
drwxr-xr-x 2 root root 60 Jul 30 12:17 .
drwxr-xr-x 19 root root 3080 Jul 30 12:17 ..
lrwxrwxrwx 1 root root 10 Jul 30 12:17 stone:stoneshare -> /dev/md127
Estranhamente, mas o link simbólico é criado, existe um problema diferente - na criação do RAID, aleatoriamente /dev/sdb1 ou /dev/sdc1 é automaticamente marcado como defeituoso. O RAID é criado e iniciado, mas está sendo executado com 1 unidade. Às vezes, nenhuma das unidades é marcada como defeituosa e o RAID é criado sem nenhum problema.
Eu escolhi, o que eu encontrei como informação relevante para a falha do dispositivo:
[root@stone ~]# journalctl -xb
Jul 30 11:39:43 stone kernel: md: bind<sdb1>
Jul 30 11:39:43 stone kernel: md: bind<sdc1>
Jul 30 11:39:43 stone kernel: md/raid1:md127: active with 2 out of 2 mirrors
Jul 30 11:39:43 stone kernel: created bitmap (8 pages) for device md127
Jul 30 11:39:43 stone kernel: md127: bitmap initialized from disk: read 1 pages, set 14903 of 14903 bits
Jul 30 11:39:43 stone kernel: md127: detected capacity change from 0 to 1000068874240
Jul 30 11:39:43 stone kernel: md127: unknown partition table
Jul 30 11:39:43 stone systemd[1]: Starting MD array monitor...
Jul 30 11:39:43 stone systemd[1]: About to execute: /usr/lib/systemd/scripts/mdadm_env.sh
Jul 30 11:39:43 stone systemd[1]: Forked /usr/lib/systemd/scripts/mdadm_env.sh as 457
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service changed failed -> start-pre
Jul 30 11:39:43 stone systemd[457]: Executing: /usr/lib/systemd/scripts/mdadm_env.sh
Jul 30 11:39:43 stone systemd[457]: Failed at step EXEC spawning /usr/lib/systemd/scripts/mdadm_env.sh: No such file or directory
Jul 30 11:39:43 stone systemd[1]: Received SIGCHLD from PID 457 ((m_env.sh)).
Jul 30 11:39:43 stone systemd[1]: Child 457 ((m_env.sh)) died (code=exited, status=203/EXEC)
Jul 30 11:39:43 stone systemd[1]: Child 457 belongs to mdmonitor.service
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service: control process exited, code=exited status=203
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service got final SIGCHLD for state start-pre
Jul 30 11:39:43 stone systemd[1]: About to execute: /sbin/mdadm --monitor $MDADM_MONITOR_ARGS
Jul 30 11:39:43 stone systemd[1]: Forked /sbin/mdadm as 460
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service changed start-pre -> running
Jul 30 11:39:43 stone systemd[1]: Job mdmonitor.service/start finished, result=done
Jul 30 11:39:43 stone systemd[1]: Started MD array monitor.
Jul 30 11:39:43 stone kernel: md: md127 still in use.
Jul 30 11:39:43 stone kernel: md/raid1:md127: Disk failure on sdb1, disabling device.
md/raid1:md127: Operation continuing on 1 devices.
Jul 30 11:39:43 stone mdadm[460]: mdadm: No mail address or alert command - not monitoring.
Jul 30 11:39:43 stone systemd[460]: Executing: /sbin/mdadm --monitor --scan
Jul 30 11:39:43 stone systemd[1]: Received SIGCHLD from PID 460 (mdadm).
Jul 30 11:39:43 stone systemd[1]: Child 460 (mdadm) died (code=exited, status=1/FAILURE)
Jul 30 11:39:43 stone systemd[1]: Child 460 belongs to mdmonitor.service
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service: main process exited, code=exited, status=1/FAILURE
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service changed running -> failed
Jul 30 11:39:43 stone systemd[1]: Unit mdmonitor.service entered failed state.
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service: cgroup is empty
Jul 30 11:39:43 stone kernel: RAID1 conf printout:
Jul 30 11:39:43 stone kernel: --- wd:1 rd:2
Jul 30 11:39:43 stone kernel: disk 0, wo:1, o:0, dev:sdb1
Jul 30 11:39:43 stone kernel: disk 1, wo:0, o:1, dev:sdc1
Jul 30 11:39:43 stone systemd[1]: Got disconnect on private connection.
Jul 30 11:39:43 stone kernel: RAID1 conf printout:
Jul 30 11:39:43 stone kernel: --- wd:1 rd:2
Jul 30 11:39:43 stone kernel: disk 1, wo:0, o:1, dev:sdc1
Jul 30 11:39:43 stone kernel: md: unbind<sdb1>
Jul 30 11:39:43 stone kernel: md: export_rdev(sdb1)
Pensei que eu duvido que mdmonitor é essencial para criar o RAID.
Ambos os RAIDs são perfeitamente montados quando executados a partir do CLI, sem problemas encontrados.
Drives, por S.M.A.R.T. são saudáveis.
Os UUIDs, na realidade, não são iguais, acabei de criar os exemplos de um único RAID.
O que estou fazendo errado aqui, que está causando essas inconsistências?