Solaris 10 - É possível reinicializar um sistema a partir de um script de inicialização?

4

Eu tenho um domínio lógico convidado de teste do Solaris 10 (LDom). Eu pretendo que a rede seja reconfigurada antes de reinicializar usando um script de inicialização em /etc/rc0.d .

No momento, quando o sistema é inicializado, tudo no script de inicialização é executado como eu quero que seja, exceto que a reinicialização não ocorre.

Eu criei um script de teste e tirei tudo, exceto o essencial:

#!/sbin/sh

# MAIN

case "$1" in
start)
   if [ -f /etc/DR_Network_Configured ]; then
      exit 0
   else
      touch /etc/DR_Network_Configured
      reboot
   fi
   exit 0
   ;;
*)
   echo "Usage: $0 { start }"
   exit 1
   ;;
esac
exit 0

Se eu executar o script a partir da linha de comando, /etc/rc0.d/S99testing start , o arquivo /etc/DR_Network_Configured será criado e o sistema será reinicializado imediatamente, ou seja, o comportamento desejado.

No entanto, se eu remover o arquivo /etc/DR_Network_Configured , desligar o sistema e inicializá-lo novamente, o arquivo /etc/DR_Network_Configured será recriado pelo script durante a inicialização, mas nenhuma reinicialização subsequente ocorrerá.

Existe um mecanismo à prova de falhas para impedir que scripts de inicialização causem reinicializações infinitas? Se assim for, há uma maneira de contornar isso?

    
por Warwick 30.07.2014 / 09:32

1 resposta

3

Eu testei a transferência desse script de /etc/rc0.d para /etc/rcS.d , /etc/rc1.d , /etc/rc2.d e /etc/rc3.d com os seguintes resultados:

  • /etc/rcS.d - o mesmo comportamento de /etc/rc0.d - / etc / DR_Network_Configured é criado, mas não ocorre nenhuma reinicialização.
  • /etc/rc1.d - / etc / DR_Network_Configured não é criado e não ocorre nenhuma reinicialização.
  • /etc/rc2.d - / etc / DR_Network_Configured é criado e o sistema é reinicializado.
  • /etc/rc3.d - / etc / DR_Network_Configured é criado e o sistema é reinicializado.

Para resumir, quando o sistema é inicializado com seu padrão ( milestone/multi-user-server:default , semelhante ao nível de execução 3), ele executa scripts de inicialização localizados em /etc/rc0.d , /etc/rcS.d , /etc/rc2.d e /etc/rc3.d , mas não /etc/rc1.d .

Os comandos reboot e init não funcionam quando são executados a partir de um script de inicialização em /etc/rc0.d , /etc/rcS.d (e possivelmente /etc/rc1.d , embora eu não possa confirmar isso, pois o script de inicialização nesse diretório nunca foi executado). Eles funcionam quando executados a partir de scripts de inicialização em /etc/rc2.d e /etc/rc3.d .

Eu imagino que isso é projetado para impedir que um sistema reinicialize constantemente. Se um script de inicialização incorreto em /etc/rc2.d ou /etc/rc3.d colocar o sistema em um loop de reinicialização infinito, o sistema poderá ser facilmente reinicializado para o marco de usuário único e o script de inicialização incorreto será desativado em vez de precisar localizar inicialização alternativa mídia para inicializar, monte o volume / disco raiz e desabilite o script ofensivo.

Com base no acima, modifiquei meu script de reconfiguração de rede da seguinte forma:

  1. Mantive meu script em /etc/rc0.d para alterar as configurações de rede.
  2. Adicionada uma função a ela para que, se o sistema precisar ser reinicializado após a reconfiguração da rede, um novo script /etc/rc2.d/S99reboot seja criado, o qual reinicializará o sistema.
  3. Se o arquivo /etc/DR_Network_Configured existir e /etc/rc2.d/S99reboot existir, remova o último para evitar que o sistema reinicialize constantemente.

Meu código relevante é:

#!/sbin/sh
reboot_script="/etc/rc2.d/S99reboot"

Create_Reboot_File ()
{
   echo "#!/sbin/sh" > $reboot_script
   echo "case \"\\" in" >> $reboot_script
   echo "start)" >> $reboot_script
   echo "  init 6" >> $reboot_script
   echo "  exit 0" >> $reboot_script
   echo "  ;;" >> $reboot_script
   echo "esac" >> $reboot_script
   echo "exit 0" >> $reboot_script
   chmod 740 $reboot_script
   chown root:root $reboot_file
}

case "$1" in
start)
   if [ -f /etc/DR_Network_Configured ]; then
      [ -f $reboot_script ] && rm $reboot_script
      exit 0
   else
      # My reconfigure network functions are here
      # ...
      touch /etc/DR_Network_Configured
      Create_Reboot_File
   fi
   exit 0
   ;;
*)
   echo "Usage: $0 { start }"
   exit 1
   ;;
esac
exit 0
    
por 31.07.2014 / 03:35
desmonta uma unidade ntfs externa como não raiz Como detectar programaticamente quando um dispositivo gera uma interrupção? ______ qstntxt ___

Como detectar programaticamente quando um dispositivo gera uma interrupção? Isso pode acontecer quando um dispositivo é conectado ou desconectado.

E também neste caso: por exemplo: quando um dedo é segurado sobre um scanner de impressão digital, uma interrupção é levantada. Como detectar e possivelmente interceptar essa interrupção?

Eu quero escrever um aplicativo usando Gtkmm de modo que quando um evento ocorre como um CD sendo inserido ou um pendrive sendo conectado, eu pego a interrupção que esses dispositivos geram e uso para fazer algo no meu aplicativo, envolvendo esses dispositivos.

Se isso não puder ser feito em Gtkmm, posso interceptar a interrupção em um nível inferior e informar o aplicativo Gtkmm?

Eu estava verificando como o GParted se comporta. Inicialmente estava mostrando %code% e quando conectei meu pendrive, ele abriu automaticamente o aplicativo %code% . Quando chequei o GParted, o pendrive não estava presente no menu suspenso de dispositivos. Ele apareceu apenas quando eu selecionei “Refresh Devices” no menu do GParted ou Ctrl + R .

    
______ azszpr144883 ___
%bl0ck_qu0te%

Não, essa é uma atividade espaço do kernel . Felizmente, o kernel reporta o resultado de certos eventos através de interfaces acessíveis a partir da userland.

É um pouco ambíguo em sua pergunta se você deseja detectar quando um dispositivo de bloco está conectado, ou quando um sistema de arquivos é montado (embora pareça ser mais o antigo). Se o seu sistema usa automontagem (eles geralmente fazem por padrão), ele montará sistemas de arquivos de dispositivos de bloco quando eles estiverem conectados, caso contrário você terá que fazê-lo manualmente (por exemplo, com %code% ).

De qualquer forma, você deseja pesquisar / analisar / varrer uma interface baseada no nó de arquivo do kernel. Eu fiz isso antes em um aplicativo (na verdade, um C ++ GTK) que rastreia os dispositivos de bloco conectados e os sistemas de arquivos montados via %code% e %code% . Este é um método simples e independente de linguagem. Algumas pessoas acham isso um pouco desagradável no início porque envolve a leitura de arquivos / diretórios, mas essas interfaces não existem no disco, portanto não há sobrecarga de E / S pesada e lembre-se: %code% é uma chamada do sistema. A leitura dos nós de arquivos nas interfaces do kernel equivale à mesma coisa que uma API de %code% style, exceto, novamente, que é independente de idioma. Quando você vai ler esses nós, o kernel passa as informações que eles representam diretamente.

O diretório %code% lista os dispositivos conectados como arquivos especiais do nó do dispositivo - por exemplo, %código%. Eles são adicionados e removidos pelo kernel à medida que os dispositivos são plugados e removidos, portanto, se você rastreá-lo pesquisando em intervalos (digamos, a cada 5 segundos), é possível detectar o que há de novo e o que foi. A única complicação aqui é que, como não há API de estilo de retorno de chamada, você precisa criar seu próprio thread para isso, se quiser uma verificação contínua (talvez porque %code% exige que você clique em %code% ).

Uma alternativa provavelmente melhor para %code% seria o material em %code% . Observe que há uma diferença significativa entre %code% e %code% (veja abaixo) ou %code% na medida em que os nós do último contêm informações sobre coisas como dispositivos, enquanto os nós em %code% é uma conexão real com o dispositivo (assim, se você verificar %code% , não se incomode em ler os arquivos individuais, apenas note que eles existem).

%code% now-a-days é um link simbólico (veja também a opção %code% em %code% ) codificar%; %code% é uma interface principal do kernel do canivete suíço (consulte %code% ). Isto lista sistemas de arquivos montados ; Se você usar a montagem automática, as coisas aparecerão e desaparecerão quando o material estiver conectado / desconectado. As informações em %code% e %code% geralmente estão na forma de texto ASCII, portanto, você pode examinar esses arquivos com %code% , etc e analisá-los com funções de sequência (fluxo).

O WRT para outros tipos de dispositivos, como um scanner de impressão digital, %code% é um bom lugar para começar - %code% contém um diretório %code% e um %code% . Dispositivos de bloco são geralmente armazenamento; as informações neles podem ser acessadas aleatoriamente . Dispositivos char trocam informações com o sistema em um fluxo, o que inclui coisas como scanners, câmeras, coisas HID (dispositivo de interface humana, por exemplo, mouses e teclados). Percebo que o gtkmm tem algumas coisas de alto nível para coisas HID anexadas, presumivelmente, uma vez que elas são significativas na interação com a GUI.

    
______ azszpr146272 ___

Eu aprovo a resposta por %code% . Mas, em vez de usar a chamada do sistema %code% para verificar as alterações no sistema de arquivos, pode-se usar %code% .

Sua página man é aqui e aqui .

Há uma excelente explicação e exemplo dos criadores (desenvolvedores) de %code% aqui .

    
___