Re: lanciare un programma dopo che il primo è partito
On Thu, 6 Mar 2025, Gerlos wrote: - 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; 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? in parte sono a orari definiti, ma possono essere fatti partire e fermati in qualsiasi momento e non c'è nessuna sequenza particolare, le varie applicazioni che possono essere sulla stessa porta hanno la stessa interfaccia ma fanno funzioni leggermente diverse (per questo se già c'è una applicazione che gira, la nuova manda i comandi a questa, ma non si installa - immaginale come driver di stampa, che accettano gli stessi comandi ma sono ottimizzati per ciascuna periferica). [proprio perché sono dei driver di periferica, che hanno funzioni leggermente diverse a seconda del momento e di cosa c'è attaccato] -- Leonardo Boselli Firenze, Toscana, Europa http://i.trail.it tel:+393287329225
lanciare un programma dopo che il primo è partito
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 n -i ./ScriptParam/parametri dove n è un numero di porta su cui viena fatto partire un server http su localhost:n 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 n -k ./scriptParam/parametri99 Lo script deve controllare se la porta n è 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 ? come faccio in maniera elegante a sapere che il programma è partito ? mi viene in mente una linea ./script/progname -...(i parametri e i comandi).. & ; sleep 5 c'è qualcosa di più pulito ? (mi è venuta in mente anche la idea sporca di fare comunque partire progname, e si mi ritorna address already in use ignoralo e andare avanti. il problema è che applicazioni diverse noin ritornano sempre lo stesso error code, e potrebbero darmi errori di tipo diverso, che non vorrei perdere) -- Leonardo Boselli Firenze, Toscana, Europa
Re: lanciare un programma dopo che il primo è partito
Il 06/03/2025 19:56, Leonardo Boselli ha scritto: Da qui le due domande: come controllo se la porta è già in uso e quindi mando direttamente i comandi con curl ? Con lsof puoi vederlo senza particolari problemi: lsof -iTCP -sTCP:LISTEN -P -n|grep $porta oppure lsof -iTCP -iTCP:$porta -sTCP:LISTEN come faccio in maniera elegante a sapere che il programma è partito ? Dipende dalla definizione di "partito": lanciato, pronto in ascolto, ha già fatto qualcosa... ? Molti programmi prevedono anche un flag file dove scrivono il loro PID. Potrebbe esserti utile. -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: lanciare un programma dopo che il primo è partito
On Thu, 6 Mar 2025, Diego Zuccato wrote: Da qui le due domande: come controllo se la porta è già in uso e quindi mando direttamente i comandi con curl ? Con lsof puoi vederlo senza particolari problemi: lsof -iTCP -sTCP:LISTEN -P -n|grep $porta oppure lsof -iTCP -iTCP:$porta -sTCP:LISTEN lo vedo, ma come lo metto in un test [fra l'laltro deve controllare solo per [::1] perché su altri indirizzi, compreso 127.0.0.1, la porta potrebbe già essere in uso] . come faccio in maniera elegante a sapere che il programma è partito ? Dipende dalla definizione di "partito": lanciato, pronto in ascolto, ha già fatto qualcosa... ? pronto in ascolto Molti programmi prevedono anche un flag file dove scrivono il loro PID. Potrebbe esserti utile. non lo hanno [anche se potrei mettercelo, ma a quel punto tanto vale che crei dei file /var/run/localport18000...18012 però questo non mi tutela in caso di uscita anomala... -- Leonardo Boselli Firenze, Toscana, Europa
Re: lanciare un programma dopo che il primo è partito
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 n -i ./ScriptParam/parametri dove n è un numero di porta su cui viena fatto partire un server http su localhost:n 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 n -k ./scriptParam/parametri99 Lo script deve controllare se la porta n è 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
