Quero executar um script bash simples (referido como killprocess.sh abaixo) para eliminar um processo/serviço específico em execução em uma porta específica (digamos 8080) em uma máquina remota onde ambos tenham o sistema operacional Ubuntu 18.04.1 LTS.
Estabeleci uma conexão via ssh (openssh) da seguinte forma para executar o script. A conexão também foi estabelecida com sucesso.
sshpass -p "password" ssh -n [email protected] -f "/bin/bash /home/killprocess.sh"
O conteúdo de killprocess.sh é fornecido abaixo.
processID=$(lsof -t -i:8080)
echo $processID
kill $processID
Embora imprima corretamente o ID do processo no console, ele exibe uma mensagem de erro abaixo que indica que não é possível eliminá-lo.
: os argumentos devem ser IDs de processo ou de trabalho
Responder1
Execute o fromdos killprocess.shcomando para fazer seu script funcionar (está incluído no tofrodospacote).
Aqui está o porquê.
A mensagem de erro sugere que você escreveu seu script em um editor de texto do Windows, que lida com os finais de linha de maneira diferente (adicionando \r\nao final da linha em vez de apenas \n). A mensagem de erro é suspeita porque deveria ser algo como
bash: kill: meh: arguments must be process or job IDs
Seria gerada uma linha como você mencionou apenas se o argumento do killcomando contivesse um \rcaractere (retorno de carro). Portanto, quando a mensagem de erro é impressa, antes do terceiro dois pontos, o cursor volta para o início da linha e o restante da mensagem de erro substitui tudo o que foi impresso até agora. Isso também explica porque o killcomando reclamou: recebeu algo como 1234\r, que não pode ser um ID de processo.
Provavelmente isso ocorre porque a primeira linha do seu script é na verdade
processID=$(lsof -t -i:8080)\r
mas você não pode ver o \rpersonagem, é claro, já que não é imprimível. Você não pode vê-lo na saída da segunda linha, pois gera a linha, o cursor volta ao início, mas o caractere de nova linha faz com que o cursor vá para a próxima linha.
A propósito, o problema de finalização de linha do Unix/Windows é sempre suspeito se uma mensagem de erro do bash começar com dois pontos.