Re: lanciare un programma dopo che il primo è part ito
Gerlos <[email protected]>
| Newsgroups | gmane.linux.debian.user.italian |
|---|---|
| Message-ID | <[email protected]> |
Ciao, Il 06/03/25 19:56, Leonardo Boselli ha scritto: > Sembra facile ma: > - ho una serie di script che vengono lanciati da at (ma potrebbe > essere anche crontab, da console o da qualunque altro programma) a > orari definiti; > - questi script debbono venir lanciati con comandi del tipo: > ~/Script/scriptname -p nnnnn -i ./ScriptParam/parametri > dove nnnnn è un numero di porta su cui viena fatto partire un > server http su localhost:nnnnn e ./scriptParam/parametri00 è un file > che contiene i parametri (sotto forma di chiamate GET da inviare al > server) > - in alternativa esiste la chiamata > ~/Script/sempreloostessonome -p nnnnn -k ./scriptParam/parametri99 > > Lo script deve controllare se la porta nnnnn è già "occupata" da un > processo in ascolto: se la porta è occupata allora invia una serie di > richieste al processo in ascolto [qualunque sia]; se invece la porta è > libera fa partire il processo server e quando questo è partito > inviargli io comandi. > Da qui le due domande: come controllo se la porta è già in uso e > quindi mando direttamente i comandi con curl ? La butto là, un po' rapidamente perché sono di fretta: perché non sfruttare il fatto che systemd è in grado di avviare servizi utente (systemctl --user) a orari definiti, e che ci sono degli automatismi (come "Wants=", "Require=" e "After=") che permettono di impostare relazioni di dipendenza tra i servizi? Ad esempio, se la unit che avvia lo script A rileva che il servizio è pronto, con l'istruzione "After=" puoi dirgli di lanciare la unit che avvia lo script B. Ora, se non hai mai pasticciato con systemd può sembrare complicato, e il fatto che con systemd si possa fare un sacco di roba confonde, ma per queste cose mi sembra l'approccio più facile e robusto. saluti, Gerlos