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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.