În multe instalări Linux, serviciile pornesc imediat la boot și rămân active chiar și atunci când nu sunt folosite. Pentru unele aplicații, modelul acesta este perfect. Pentru altele însă, systemd oferă o variantă mai eficientă: socket activation. Pe scurt, în loc să pornești serviciul din start, îi lași lui systemd sarcina de a asculta pe un socket sau pe un port, iar procesul real este lansat doar când apare prima conexiune.
Ideea nu este nouă, dar în systemd este integrată curat și bine documentat. Poate fi utilă pentru servicii administrative, unelte interne, demoni rar folosiți sau componente care nu trebuie să consume resurse permanent. Nu este o soluție universală, însă pentru scenariile potrivite poate simplifica pornirea și poate reduce numărul de procese active după boot.
Ca să funcționeze, ai nevoie de două unități diferite: un fișier .socket, care definește unde ascultă systemd, și un fișier .service, care descrie procesul ce va fi pornit la cerere. Conform documentației oficiale systemd, pentru fiecare socket unit trebuie să existe un service unit corespunzător, iar numele este de regulă același. De exemplu, app.socket lucrează cu app.service.
Fișierul .socket conține de obicei secțiunea [Socket] și o directivă precum ListenStream=. Acolo poți specifica un port TCP, un socket Unix din filesystem sau alte tipuri de adrese suportate. Tot documentația oficială arată că poți avea și mai multe directive ListenStream= sau combinații cu ListenDatagram=, dacă aplicația are nevoie de mai multe puncte de intrare.
Fișierul .service descrie procesul lansat când apare traficul. Aici este important un detaliu pe care mulți îl scapă la început: aplicația trebuie să știe să primească socketul deschis de systemd. În mod normal, asta înseamnă suport pentru interfața de socket passing din systemd, descrisă prin sd_listen_fds(3), sau compatibilitate de tip inetd în anumite scenarii. Dacă programul tău nu știe să folosească descriptorii primiți, simpla creare a fișierelor .socket și .service nu este suficientă.
Un exemplu minimal arată așa, la nivel conceptual: în myapp.socket definești ListenStream=127.0.0.1:8080, iar în myapp.service definești ExecStart= către binarul aplicației. După ce salvezi fișierele în /etc/systemd/system/, faci systemctl daemon-reload, apoi activezi socketul cu systemctl enable –now myapp.socket. Observă diferența importantă: nu pornești direct serviciul, ci socketul. Din acel moment, systemd ascultă pe adresa configurată și lansează serviciul numai când apare prima conexiune.
Dacă vrei să verifici starea, comenzile cele mai utile sunt systemctl status myapp.socket, systemctl status myapp.service și journalctl -u myapp.service. Prima îți confirmă că punctul de ascultare este activ, a doua îți arată dacă serviciul a fost pornit corect, iar jurnalul te ajută să vezi erorile de integrare. Este o verificare importantă mai ales după modificări, pentru că un serviciu poate părea corect configurat, dar să nu știe efectiv să preia socketul transmis de systemd.
Mai există un aspect avansat care merită înțeles: Accept=. În documentația systemd.socket, Accept=no înseamnă că un singur service gestionează conexiunile pentru socketul respectiv. Accept=yes schimbă modelul și cere un serviciu template de forma nume@.service, din care systemd poate crea instanțe separate pentru fiecare conexiune. Pentru multe servicii moderne, Accept=no este mai simplu și mai ușor de administrat. Accept=yes este util doar în cazurile în care arhitectura aplicației chiar cere instanțe separate pe conexiune.
Când merită folosit? În special pentru servicii locale sau interne accesate rar, pentru utilitare de administrare, pentru componente care trebuie izolate mai bine sau pentru sisteme unde vrei să eviți pornirea inutilă a unor demoni la boot. Când nu merită? Atunci când aplicația are trafic constant, când timpul de răspuns la prima conexiune trebuie să fie absolut minim sau când software-ul nu suportă corect mecanismul de socket passing.
Dacă vrei o implementare sigură, începe cu o aplicație simplă, testează numai pe localhost, verifică jurnalele și nu expune direct pe internet un serviciu nou fără filtrare de rețea, autentificare și actualizări la zi. Socket activation este o unealtă excelentă în Linux administrat atent, dar funcționează bine doar când aplicația și unitățile systemd sunt aliniate corect.
