Fornecer aos usuários normais (não raiz) recursos de inicialização automática e inicialização

7

Estou hospedando uma caixa Linux experimental / testing, rodando a distribuição Debian Wheezy 7.4.0. Usuários diferentes fazem login na máquina por meio do ssh em suas contas e têm permissão para executar as ferramentas de desenvolvimento e deixar seus programas em execução como serviços em segundo plano, se assim o desejarem.

Como essa é uma máquina de teste para todos os tipos de propósitos, geralmente é necessário reiniciar a máquina inteira e, em seguida, os usuários precisam efetuar login novamente e reiniciar o material que estava em execução no espaço do usuário. Eu gostaria de automatizar isso. Basicamente eu gostaria de fornecer aos usuários um meio de lançar coisas logo após o arranque da máquina (depois de tudo ter sido inicializado) e um meio de lançar coisas após o desligamento do sistema (sem limitações de tempo, basicamente parando o desligamento até que todos desliguem processos do usuário foram concluídos).

O que tentei até agora:
Eu criei um script init bash, seguindo os princípios encontrados no arquivo de modelo 'esqueleto' em /etc/init.d/ (código-fonte do modelo Skeleton: link )

Meu código está aqui: link

Basicamente, o script passa pelos diretórios iniciais dos usuários e procura por arquivos executáveis nos subdiretórios correspondentes chamados .startUp, .shutDown ou .status. Dependendo do evento que está sendo executado, os scripts serão executados com su como se os usuários tivessem iniciado eles mesmos.

O problema que estou enfrentando atualmente com essa abordagem é que há um processo estranho deixado pendurado depois que o sistema é inicializado e o script inicia todos os processos de outros usuários. É assim que parece na lista de processos:

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
root      3053     1  0  1024   620   1 17:42 ?        00:00:00 startpar -f -- userspaceServices

Eu não sei o que é esse processo e a man page não menciona o argumento -f. Então, eu estou sem noção, mas devo estar fazendo algo errado, já que nenhum outro script / serviço do init.d deixa um processo assim após a inicialização.

Então eu estou procurando alguém para me ajudar a depurar esta solução que tenho (o que também parece um pouco complexo na minha opinião). Ou me dê uma ideia de como isso poderia ser implementado de uma maneira totalmente diferente.

UPDATE
Eu comecei uma pergunta separada para o problema startpar : processo startpar deixado pendurado ao iniciar processos de rc.local ou init.d

UPDATE 2
Problema resolvido para minha solução original. Verifique a questão mencionada anteriormente para startpar . O código no GitHub também é corrigido para refletir isso.

UPDATE 3 - Como usar o crontab
Como Jenny sugeriu, usuários regulares podem agendar tarefas para serem executadas uma vez na inicialização usando o crontab. Eu acho que para ser o método mais fácil, se tudo que você precisa é iniciar as tarefas do usuário na inicialização e não no desligamento. No entanto, há uma desvantagem de os usuários poderem deixar o processo cron "suspenso" como pai quando iniciam tarefas contínuas semelhantes a serviços. Primeiro, deixe-me explicar como funciona:

usuários regulares devem ligar:

crontab -e

(-e como em editar ) Que abre um editor de texto de console padrão com seu arquivo crontab de usuário. Para adicionar uma tarefa a ser executada na inicialização, o usuário deve adicionar uma linha ao final do arquivo:

@reboot /path/to/the/executable/file

Agora, se o usuário fizer exatamente isso e se esse arquivo não for apenas um script simples que conclua algo linearmente e termine, mas algum tipo de watchdog, por exemplo, após uma reinicialização, você terminará com algo assim em sua lista de processos :

    1  2661 root       20   0 20380   860   660 S  0.0  0.0  0:00.00 ├─ /usr/sbin/cron
 2661  2701 root       20   0 33072  1152   868 S  0.0  0.0  0:00.00 │  └─ /USR/SBIN/CRON
 2701  2944 someuser   20   0  4180   580   484 S  0.0  0.0  0:00.00 │     └─ /bin/sh -c ./watchdog
 2944  2945 someuser   20   0 10752  1204  1016 S  0.0  0.0  0:00.00 │        └─ /bin/bash ./watchdog
 2945  2946 someuser   20   0 23696  4460  2064 S  0.0  0.1  0:00.01 │           └─ /usr/bin/python ./some_program.py

Para evitar que o usuário precise modificar sua entrada crontab para ficar assim:

@reboot /path/to/the/executable/file >/dev/null 2>&1 &

Os redirecionamentos de descritores de arquivos são opcionais, mas recomendados para mantê-los limpos. Se você quer estudar o porquê, tente olhar para eles:

ls -l /proc/pid_of_started_process/fd
    
por Ivan Kovacevic 01.04.2014 / 18:09

1 resposta

8

Eu concordo que sua solução parece um pouco complexa, então eu vou com "me dê uma idéia de como isso poderia ser implementado de uma maneira totalmente diferente": -)

  1. A solução padrão para isso é usar um sistema de gerenciamento de configuração, como o fantoche, e permitir que os usuários adicionem seus itens à configuração do boneco do servidor. O Puppet enviará o script de início e os adicionará aos runlevels relevantes.

  2. Uma maneira mais rápida seria dar a eles acesso sudoedit a /etc/rc.d/rc.local e adicionar suas coisas lá.

  3. Ou dê a cada um deles um diretório para colocar os scripts de início que eles querem, e faça um trabalho cron copiar esses scripts para /etc/init.d , inserindo su $USER -c em lugares apropriados e execute chkconfig neles.

  4. Ou dê a cada um deles um diretório para colocar os scripts de início e adicione algumas linhas no final fo /etc/rc.d/rc.local para passar por esses diretórios e executar editado su $USER -c 'script start' em cada script neles.

Editado para adicionar: 5. Deixe-os usar crontab para agendar os trabalhos a serem executados @reboot

    
por 01.04.2014 / 18:24