Harness MaxxingDocumentazione
📚 Tutte le pagine

💬 Usare Harness Maxxing · 6 min di lettura

⏰Job pianificati (Crons)

La pagina Crons esegue operazioni in modo pianificato: un comando shell o un prompt di Harness in un topic. Ogni esecuzione viene registrata (stato, durata, output) e può essere segnalata su Telegram.

Creare un job

Clicca su New job e compila:

Campo Significato
Nome etichetta breve
Pianificazione espressione cron; l'editor la mostra a parole e elenca le prossime esecuzioni
Tipo Shell (un comando eseguito con bash) o Claude (un prompt inviato a una sessione in un topic)
Comando shell: ad es. /root/maxxing/projects/acme/scripts/report.sh
Topic, prompt, modello Claude: dove viene eseguita la sessione, cosa fare, quale modello usare
Riutilizza la sessione Claude: mantiene una sola sessione tra le esecuzioni (accumula contesto) invece di una nuova sessione ogni volta
Notifica report su Telegram: mai, in caso di errore (predefinito), sempre
Timeout durata massima (predefinita 1 ora)

Run now avvia subito un job. La cronologia mostra le ultime esecuzioni con la coda del loro output; per i job Claude, un link apre la sessione.

Sintassi della pianificazione

Cinque campi: minute hour day-of-month month day-of-week.

Espressione Esecuzione
0 7 * * * ogni giorno alle 07:00
*/15 * * * * ogni 15 minuti
30 8 * * 1-5 nei giorni feriali alle 08:30
0 9 1 * * il 1° di ogni mese alle 09:00
0 */6 * * * ogni 6 ore
@daily, @hourly, @weekly, @monthly, @reboot scorciatoie

Fuso orario

Il demone cron avvia i job nel fuso orario di sistema del server, mentre l'interfaccia (anteprima della pianificazione, prossime esecuzioni, cronologia) usa il fuso orario di Settings -> General. I due devono coincidere, altrimenti un job mostrato "alle 07:00" viene eseguito a un'altra ora. Su un server nuovo, il fuso che scegli durante l'onboarding (o in Settings -> General) diventa anche il fuso di sistema; maxxing doctor ti avvisa se differiscono.

Su un server già in uso (altri job pianificati, altri servizi), l'installer mantiene l'orologio del server (system_clock = keep nella configurazione): Harness Maxxing scrive allora la riga crontab di ogni job in modo che scatti ogni ora ai suoi minuti, e maxxing cron run <id> --if-due controlla la pianificazione nel tuo fuso prima di eseguire - così i job girano comunque agli orari che vedi, ora legale compresa, e gli altri programmi mantengono il loro orologio. Puoi passare da una modalità all'altra con maxxing init --system-clock keep|follow.

Per cambiare a mano il fuso di sistema (modalità follow):

timedatectl set-timezone Europe/Paris && systemctl restart cron
maxxing init --timezone Europe/Paris && systemctl restart claude-maxxing

Job integrati

  • Memory compaction – ogni giorno alle 05:00, job Claude che usa la skill memory-compaction (creato durante l'installazione, attivato quando termini l'onboarding con Claude connesso - così non fallisce mai prima che Claude sia collegato; se hai saltato quel passaggio, attivalo nella pagina Crons; puoi modificarlo, disattivarlo o eliminarlo).
  • Memory backup – creato quando configuri il Backup (predefinito 04:40).
  • Check for updates – il lunedì alle 09:00, job shell maxxing update --check --notify: quando esiste una nuova versione, un messaggio Telegram ti dice di aprire il topic system/harness (system/update sui server installati prima della 2.0.0a33) e di scrivere "update". Non si aggiorna mai da solo. Su un server senza git remote né licenza (una copia locale) viene creato disattivato (non c'è nulla da controllare); maxxing update --check risponde allora "updates unavailable (no git remote)".
  • Morning tasks (disattivato) – ogni giorno alle 08:00, job Claude in general/inbox (system/tasks prima della 2.0.0a33): attività scadute e di oggi, inviate su Telegram. Attivalo nella pagina Crons.
  • Renewal reminder – creato quando richiedi i promemoria degli abbonamenti (il lunedì alle 09:30, nel topic che contiene accounts.md); i server installati prima della 2.0.0a33 lo hanno disattivato in system/accounts.
  • Gli Starter projects aggiungono i propri job, creati disattivati.

I job integrati vengono creati una sola volta, durante l'installazione (o con l'aggiornamento che li ha introdotti); un job che elimini non viene mai ricreato. Con la notifica "sempre", il report include l'output del job (la risposta di un job Claude), così un promemoria arriva come messaggio leggibile.

Come funziona

Ogni job attivo diventa una riga nel crontab di root, all'interno di un blocco gestito da Harness Maxxing:

# >>> claude-maxxing (managed) >>>
0 5 * * * MAXXING_CRON_DETACH=1 /usr/local/bin/maxxing cron run c_3fa91c >/dev/null 2>&1
# <<< claude-maxxing <<<

Le righe fuori dal blocco sono tue e non vengono mai toccate; compaiono in sola lettura come job "esterni". Se la riga di chiusura del blocco viene eliminata a mano, solo le righe maxxing cron run sono considerate gestite: le tue righe successive vengono mantenute. Da un terminale: maxxing cron list, maxxing cron run <id> (lo esegue nel tuo terminale e attende), maxxing cron sync (riscrive il blocco), maxxing cron deleted (i job rimossi che sono stati conservati) e maxxing cron restore <id> (ne ripristina uno). Due esecuzioni dello stesso job non si sovrappongono mai.

Memoria e limiti di tempo

Un'esecuzione pianificata parte esattamente come Run now: nella propria unit systemd (maxxing-cron-<id>, vedi journalctl -u maxxing-cron-<id>), così un job vorace non può mettere fuori uso l'intero server di notte:

  • ogni job può usare al massimo unit_memory_max della RAM (predefinito 75 %, lo stesso limite di una sessione);
  • tutti i job in esecuzione nello stesso momento condividono un unico budget, jobs_memory_max (predefinito 75 % della RAM, la unit maxxing-jobs.slice). Per modificarlo, imposta jobs_memory_max in /var/lib/claude-maxxing/config.json ("3G", "50%", oppure "" per nessun limite), poi esegui maxxing init;
  • allo scadere del timeout, un job shell riceve un segnale di arresto, poi 5 secondi dopo tutto ciò che ha avviato viene terminato forzatamente, anche un programma che ignora il segnale di arresto.

Quando il job termina, anche i programmi che ha lasciato in esecuzione in background terminano con lui. Per avviare un programma che deve restare in esecuzione (un server, un bot), crea un servizio systemd invece di un job cron (chiedilo a Claude). Le installazioni fatte prima della 2.0.0-alpha.70 mantengono il vecchio comportamento: i loro job pianificati girano nel processo cron come prima, quindi i programmi che lasciano in background restano in esecuzione, senza i limiti di memoria descritti sopra ("cron_keep_background": true in config.json; impostalo su false per ottenere le unit dei job). Lo stesso vale per le protezioni delle sessioni e dei job ("unit_hardening": false lì; true le attiva).

Su un server senza systemd (alcuni container), il job gira dentro il processo cron: il timeout vale comunque, i limiti di memoria no.

I segreti contrassegnati come "expose" in Settings -> Keys sono disponibili come variabili d'ambiente per i job shell e le sessioni Claude.

Un job shell viene eseguito con la stessa configurazione di Claude delle tue sessioni (la cartella Claude Code di Harness e l'account Claude collegato in Harness), quindi uno script può chiamare a sua volta claude -p "..." - per esempio uno script che prepara dei dati, chiede un testo a Claude, poi lo pubblica.

Consigli per i job Claude

Scrivi il prompt come un'istruzione completa: cosa produrre, dove scriverlo, quale skill usare. Il job non ha nessuna conversazione precedente, a meno che "Riutilizza la sessione" non sia attivo.

💡 Bloccato? Apri una sessione nel topic system › help e chiedi con parole tue: Claude legge questa documentazione sul tuo server e ti risponde.✏️ Migliora questa pagina