systemd-run με user scopes: έλεγχος των development processes

Το systemd-run με user scopes είναι ένας απλός τρόπος να βάζετε ένα προσωρινό development process σε δικό του, ορατό και ελεγχόμενο cgroup χωρίς να γράφετε μόνιμο unit file. Αν ένα τοπικό build, ένας dev server ή ένα εργαλείο εισαγωγής δεδομένων αρχίσει να καταναλώνει υπερβολική μνήμη ή CPU, συχνά το σταματάμε από το terminal και έπειτα ψάχνουμε παιδιά processes με ps. Με transient scope, το ίδιο workload αποκτά όνομα, εμφανίζεται στο systemctl --user, αφήνει ίχνος στο journal και μπορεί να έχει προσωρινά όρια πόρων.

Δεν είναι αντικατάσταση του Docker ούτε μηχανισμός ασφαλούς sandboxing. Είναι εργαλείο οργάνωσης και παρατήρησης processes που ήδη εκτελείτε στο Linux desktop ή workstation. Αυτό το κάνει κατάλληλο για εργασίες που πρέπει να ξεκινήσουν γρήγορα, να μη μείνουν ξεχασμένες στο background και να καθαρίσουν προβλέψιμα όταν τελειώσει η δοκιμή.

Τι δημιουργεί το systemd-run

Η τεκμηρίωση του systemd περιγράφει το systemd-run ως εργαλείο που ξεκινά transient service ή scope units. Με την επιλογή --scope, η εντολή δημιουργεί ένα προσωρινό .scope αντί για το προεπιλεγμένο .service. Η διαφορά έχει σημασία όταν ένα command παραδώσει τον έλεγχο σε παιδιά processes ή αποσυνδεθεί από το terminal: ένα scope παρακολουθεί την ομάδα διεργασιών του cgroup και όχι ένα μόνο main process.

Για προσωπικές development εργασίες προτιμήστε τον user manager με --user. Δεν χρειάζεστε root, δεν πειράζετε το system-wide system.slice και τα units σας μένουν διαχωρισμένα από υπηρεσίες του λειτουργικού. Το ακόλουθο παράδειγμα ξεκινά local server με εύκολο όνομα:

systemd-run --user --scope --unit=demo-api \
  --description=local-demo-api \
  npm run dev

Η εντολή δεν μετατρέπει το project σε daemon ούτε αποθηκεύει αρχείο στο ~/.config/systemd/user. Το unit υπάρχει όσο υπάρχει το workload. Για έλεγχο χρησιμοποιήστε systemctl --user status demo-api.scope. Το suffix είναι χρήσιμο: όταν δίνετε --unit=demo-api, το transient scope εμφανίζεται ως demo-api.scope.

Γιατί όχι ένα background command

Ένα npm run dev & αρκεί για πολύ μικρές δοκιμές, αλλά χάνει την αξία του όταν το command ξεκινά watchers, workers ή browser automation. Το shell γνωρίζει κυρίως το αρχικό job, ενώ το systemd δείχνει το unit, το cgroup και τα logs του ως ενιαίο σύνολο. Η systemd-cgls --user βοηθά να επιβεβαιώσετε ποια processes βρίσκονται κάτω από το scope, και η journalctl --user-unit=demo-api.scope συγκεντρώνει output χωρίς να ψάχνετε παλιά terminals.

Το lifecycle γίνεται επίσης ρητό. Για καθαρό τερματισμό χρησιμοποιήστε systemctl --user stop demo-api.scope. Έτσι ζητάτε από το unit να σταματήσει αντί να στέλνετε τυχαία σήματα σε process IDs. Αν η διαδικασία έχει δικά της παιδιά, το cgroup προσφέρει πολύ καθαρότερη εικόνα για το τι ανήκει στη δοκιμή και τι όχι.

Προσωρινά όρια CPU και μνήμης

Το systemd-run δέχεται properties με --property= στην ίδια μορφή που χρησιμοποιεί το systemctl set-property. Για ένα πειραματικό frontend build που δεν θέλετε να μονοπωλεί τον φορητό υπολογιστή, μπορείτε να ορίσετε όριο μνήμης και CPU:

systemd-run --user --scope --unit=heavy-build \
  --property=MemoryMax=3G \
  --property=CPUQuota=150% \
  pnpm run build

Το MemoryMax=3G είναι όριο για το cgroup του unit, ενώ το CPUQuota=150% εκφράζει quota έως ενάμισι λογικό CPU. Οι τιμές δεν είναι συνταγή για κάθε project: ένα static site μπορεί να χρειάζεται πολύ λιγότερα, ενώ ένα build με native εργαλεία ίσως χρειάζεται περισσότερο χώρο. Ο στόχος είναι ένα ρεαλιστικό ταβάνι για το πείραμα, όχι μόνιμη ρύθμιση του συστήματος.

Αν το unit αποτύχει, μην θεωρήσετε αυτομάτως ότι το systemd είναι η αιτία. Ελέγξτε logs με journalctl --user-unit=heavy-build.scope -e και status με systemctl --user status heavy-build.scope. Ένα memory limit μπορεί να αποκαλύψει ότι το build ξεπερνά όντως το διαθέσιμο budget, ενώ λάθος command θα φαίνεται ως συνηθισμένο failure εκκίνησης. Αυτή η παρατηρησιμότητα είναι ο λόγος που το transient unit υπερτερεί από ένα ξεχασμένο terminal tab.

Scope ή transient service

Το --scope ταιριάζει σε interactive ή child-process-heavy εργασίες. Για command που θέλετε να αντιμετωπιστεί ως υπηρεσία του systemd, αφήστε το scope εκτός και δημιουργήστε transient service. Η επίσημη τεκμηρίωση σημειώνει ότι ο προεπιλεγμένος τύπος transient service είναι simple: το systemd μπορεί να θεωρήσει ότι η εκκίνηση πέτυχε μόλις γίνει fork, πριν επιβεβαιωθεί το execve. Όταν η επιβεβαίωση εκκίνησης είναι κρίσιμη, το --property=Type=exec είναι καταλληλότερο.

Η επιλογή δεν είναι θέμα καλύτερου unit αλλά ownership. Ένα scope οργανώνει workload που ανήκει στην interactive συνεδρία. Ένα service είναι καλύτερο όταν το systemd έχει τον ξεκάθαρο ρόλο εκκινητή και manager της υπηρεσίας. Μην αντιγράφετε τυφλά παραδείγματα παραγωγής στο laptop: για απλό dev server, το ξεκάθαρο όνομα και τα logs συνήθως αρκούν.

Ένα μικρό workflow

1. Ξεκινήστε χωρίς limits, με systemd-run --user --scope --unit=project-check και το command της δοκιμής σας.
2. Επιβεβαιώστε με systemctl --user status project-check.scope ότι το unit και το command είναι όσα περιμένατε.
3. Δείτε output με journalctl --user-unit=project-check.scope -f αντί να στηρίζεστε μόνο στο terminal scrollback.
4. Προσθέστε ένα μόνο όριο, όπως MemoryMax, και μετρήστε αν το workload συνεχίζει να λειτουργεί σωστά.
5. Σταματήστε το unit με systemctl --user stop project-check.scope όταν ολοκληρωθεί η δοκιμή.

Το workflow ταιριάζει σε μικρά proof-of-concept projects, όπως μία από τις ιδέες για developer portfolio. Μπορείτε να τρέξετε import, build ή local server με αναπαραγώγιμο όνομα και να καταγράψετε τι έγινε, χωρίς να δεσμεύσετε το setup σε μόνιμο service file. Είναι και ένας πρακτικός τρόπος εξοικείωσης με cgroups πριν τα συναντήσετε σε CI runners ή production Linux hosts.

Προϋποθέσεις και παγίδες

Χρειάζεστε Linux με ενεργό systemd user manager. Οι περισσότερες σύγχρονες διανομές που χρησιμοποιούν systemd το παρέχουν σε κανονική γραφική ή SSH συνεδρία, αλλά οι λεπτομέρειες του session lifecycle διαφέρουν. Αν θέλετε user unit να συνεχίσει μετά το τελευταίο logout, εξετάστε προσεκτικά user lingering και πολιτικές διανομής. Δεν είναι απαραίτητο για αυτόν τον προσωρινό οδηγό και δεν πρέπει να ενεργοποιείται απλώς για να δουλέψει ένα dev command.

Τέλος, τα resource controls δεν είναι όριο ασφάλειας απέναντι σε μη αξιόπιστο κώδικα. Δεν απομονώνουν δίκτυο, filesystem permissions ή credentials. Για τέτοια περίπτωση χρειάζεστε διαφορετικό μοντέλο απομόνωσης και threat model. Το systemd-run με user scopes λύνει ένα πιο πεζό αλλά συχνό πρόβλημα: να ξέρετε ποια development διαδικασία τρέχει, πού είναι τα logs της και πώς σταματά καθαρά.

Πηγές

• systemd-run(1): transient units και scopes
• systemd.scope(5): lifecycle των scope units
• systemd.resource-control(5): MemoryMax και CPUQuota