Exec in background e strumento process in OpenClaw

È nel lavoro di lunga durata che uno strumento shell diventa utile oppure diventa un problema. La risposta di OpenClaw è mandare il comando in background, restituire un ID di sessione e dare all’agente uno strumento separato per interrogarlo, alimentarlo e terminarlo. I dettagli che vale la pena conoscere sono quelli che decidono se l’output sopravvive, se il processo sopravvive e cosa dovrebbe fare l’agente invece di dormire.

Passaggio in background e conservazione

• Un’esecuzione in primo piano restituisce direttamente l’output conservato e segnala quando l’output precedente ha superato il limite aggregato; quando il comando passa in background, esplicitamente o superando il ritardo di rilascio, lo strumento restituisce uno stato running, un ID di sessione e una breve coda, e le esecuzioni in background ereditano comunque il timeout exec configurato, a meno che la chiamata non ne passi uno proprio.
• Restituire un ID di sessione non ferma il timeout del processo: per un servizio persistente sul gateway o in una sandbox, manda il comando in background con il timeout disattivato e fermalo più tardi con l’azione kill, mentre i limiti di ciclo di vita dell’host e del worker restano validi.
• L’output resta in memoria fino al limite aggregato per sessione finché la sessione non viene interrogata o ripulita; le sessioni terminate scadono dopo una durata misurata dal completamento, con ogni exec che acquisisce l’impostazione di conservazione del proprio agente al momento dell’ammissione, e il registro conserva al massimo 50 sessioni terminate e due milioni di caratteri, eliminando prima le più vecchie, mentre la sessione completata più recente mantiene il proprio aggregato limitato.
• I parametri esistono come chiavi di configurazione e non come variabili d’ambiente: il ritardo per il passaggio in background è di dieci secondi per impostazione predefinita, il timeout per chiamata di 1800 secondi, la durata prima della pulizia di 30 minuti, la notifica di uscita è attiva per impostazione predefinita e accoda un evento di sistema più una richiesta di heartbeat, e un’impostazione aggiuntiva può notificare anche le esecuzioni riuscite che non hanno prodotto output.

Il polling serve per lo stato su richiesta, non per programmare cicli di attesa. Se il lavoro deve avvenire più tardi, usa cron.

Worker, pulizia e strumento process

Su un nodo abbinato o su un worker cloud basato su nodo, i processi in background appartengono all’ambiente della sessione: terminare o annullare un turno lascia in esecuzione i comandi già passati in background, un turno successivo nello stesso ambiente può interrogarli, alimentarli o fermarli, e i comandi in primo piano si fermano comunque quando il loro turno viene annullato. Il worker trattenuto occupa uno slot worker del nodo, riutilizzarlo non richiede slot aggiuntivi, e quando un turno termina senza comandi in background attivi il worker esce. Spostare o ritirare l’ambiente, sostituirne la titolarità o fermare il nodo ferma anche i suoi processi, e gli handle non sopravvivono a un riavvio del worker o del nodo. Anche altrove la pulizia è volutamente prudente: per i gruppi di processi posseduti attende che il sistema operativo confermi la scomparsa del gruppo, un comando completato o una pipe di output chiusa da soli non dimostrano che i discendenti si siano fermati, e una terminazione forzata senza pulizia confermata resta incerta invece di essere segnalata come uno spegnimento pulito.

Le nove azioni

• L’azione list mostra le sessioni in esecuzione e terminate con un nome derivato, poll svuota il nuovo output e riporta lo stato di uscita, log legge l’output aggregato con paginazione per righe e suggerimenti per il recupero dell’input, e tutte e tre segnalano una sessione come in attesa di input solo quando stdin è ancora scrivibile e la sessione è rimasta inattiva oltre la soglia.
• L’azione write invia dati su stdin con un marcatore di fine opzionale, send-keys invia token di tasti espliciti o byte a una sessione basata su terminale, submit invia un ritorno a capo e paste invia testo letterale racchiuso per impostazione predefinita in un bracketed paste; kill termina una sessione in esecuzione, clear rimuove una sessione terminata e remove fa quella delle due che si applica.
• Solo le sessioni passate in background vengono elencate e conservate, in memoria e mai su disco, quindi vanno perse a un riavvio; lo strumento è limitato al singolo agente e vede solo le sessioni di quell’agente, una sessione in background attiva blocca la sospensione cooperativa e il riavvio sicuro del gateway finché l’uscita non è confermata, e un timeout di poll superiore a 30 secondi viene ricondotto a quel limite.

Lo strumento exec di OpenClaw è lo strumento che avvia queste sessioni e le attività in background di OpenClaw sono il registro che le mostra mentre sono in esecuzione.

Cosa fare invece di dormire

La documentazione è netta sull’anti-pattern: non emulare promemoria o solleciti differiti con cicli di sleep o polling ripetuto. Per il lavoro che inizia adesso, avvialo una sola volta e affidati al risveglio automatico al completamento, quando è attivo e il comando emette output o fallisce, poi usa lo strumento process per log, stato, input o intervento. Per il lavoro che deve avvenire più tardi o secondo una pianificazione, la superficie giusta è il pianificatore. Leggere il log prima di recuperare un comando interattivo è l’altra abitudine da mantenere, perché la trascrizione, lo stato di stdin e il suggerimento di attesa dell’input sono visibili insieme solo lì. La guida alle automazioni di OpenClaw copre il pianificatore e l’articolo sulla sandbox di OpenClaw spiega dove questi comandi girano davvero.

Su Diali

Su Diali l’assistente gira nel proprio runtime con lo stato su un volume persistente, quindi un comando in background appartiene soltanto a quel runtime del cliente; snapshot giornalieri e ripristino con un clic sono disponibili tramite il componente aggiuntivo Backup (incluso in Max). OpenClaw ospitato su Diali descrive l’assistente ospitato e la pagina sulla sicurezza di Diali il perimetro attorno a ciò che può eseguire.

• Superato il ritardo di rilascio, un comando restituisce un ID di sessione, non un muro di output.
• Solo in memoria: le sessioni vanno perse al riavvio, sono limitate e scadono.
• Il risveglio al completamento batte il polling; il pianificatore batte lo sleep.