Upgrade to Pro — share decks privately, control downloads, hide ads and more …

systemd: The Good Parts

systemd: The Good Parts

Even though there is some dissatisfaction with systemd in the sysadmin community, James Nugent, an engineer at Samsung Research, shows why it largely fulfills its primary purposes.

In this talk he takes a tour of the great, and sometimes unappreciated or lesser-known features of systemd. He also explains how it can be paired with Packer and Terraform as a component of self-healing systems, and how it can also be used in a production-grade Consul cluster.

James Nugent

July 11, 2018
Tweet

More Decks by James Nugent

Other Decks in Technology

Transcript

  1. systemd: The Good Parts James Nugent Samsung Electronics @jen20

  2. None
  3. None
  4. None
  5. None
  6. None
  7. Fedora 15 May 2011 openSUSE 12.2 September 2012 CentOS 7.14.04

    April 2014 Red Hat Enterprise Linux 7.0 June 2014 SUSE Linux Enterprise Server 12 October 2014 Debian 8 April 2015 Ubuntu 15.04 April 2015 systemd Adop+on
  8. Fedora 15 May 2011 openSUSE 12.2 September 2012 CentOS 7.14.04

    April 2014 Red Hat Enterprise Linux 7.0 June 2014 SUSE Linux Enterprise Server 12 October 2014 Debian 8 April 2015 Ubuntu 15.04 April 2015 systemd Adop+on
  9. None
  10. None
  11. systemd

  12. Aspects of systemd • System and service manager • This

    is what we’ll focus on today • So2ware pla6orm for developing other applica9ons • We’ll touch on this too • “Glue” between the kernel and user applica9ons • Some references at the end
  13. Units

  14. Units

  15. Unit File Paths • /lib/systemd/system • For package-installed units •

    /etc/systemd/system • For Administrator-configured units • /run/systemd/system • For non-persistent run9me modifica9ons
  16. name.type

  17. name.type consul.service

  18. name.type ssh.socket

  19. Service Units

  20. None
  21. None
  22. None
  23. Service Unit Types • Simple (default) - for executables which

    run without daemonising - like Consul. • Forking - for executables which daemonise themselves • Oneshot - usually short-lived programs which run to comple9on and terminate • No+fy - for executables which will no9fy systemd when they are started and available for work. • Consul now supports this - more later!
  24. Unit Commands • systemctl enable consul.service • systemctl start consul.service

    • systemctl stop consul.service • systemctl restart consul.service • systemctl status consul.service
  25. systemctl status consul.service

  26. systemctl status consul.service Unit Name & Descrip9on

  27. systemctl status consul.service Unit Name & Descrip9on Enabled Status

  28. systemctl status consul.service Unit Name & Descrip9on Enabled Status Up9me

  29. systemctl status consul.service Unit Name & Descrip9on Enabled Status Up9me

    All processes
  30. systemctl status consul.service Unit Name & Descrip9on Enabled Status Up9me

    All processes Last 10 log lines
  31. “Drop-in” ConfiguraGon

  32. “Drop-in” Configura+on

  33. “Drop-in” Configura+on Per-Service Drop-In Configura9on Directory

  34. “Drop-in” Configura+on Loaded Drop-in Configura9on Files

  35. systemd-delta

  36. Common Bootstrapping PaGern • Install so2ware from a generic package

    • apt-get install consul • Install bootstrapping script and drop-in configura9on from an environment-specific package • apt-get install consul-bootstrap-aws • apt-get install consul-bootstrap-azure
  37. Working Example

  38. Target Units

  39. None
  40. consul-online.target network-online.target consul.service multi-user.target consul-online.service service-that-depends-on-consul.service

  41. None
  42. None
  43. None
  44. Socket Units

  45. If a service dies, its listening socket stays around, not

    losing a single message. After a restart of the crashed service it can continue right where it left off. If a service is upgraded we can restart the service while keeping around its sockets, thus ensuring the service is continously responsive. Not a single connection is lost during the upgrade. —Lennart Poettering
  46. If a service dies, its listening socket stays around, not

    losing a single message. After a restart of the crashed service it can continue right where it left off. If a service is upgraded we can restart the service while keeping around its sockets, thus ensuring the service is continously responsive. Not a single connection is lost during the upgrade.
  47. If a service dies, its listening socket stays around, not

    losing a single message. After a restart of the crashed service it can continue right where it left off. If a service is upgraded we can restart the service while keeping around its sockets, thus ensuring the service is continously responsive. Not a single connection is lost during the upgrade.
  48. Permissions

  49. Socket Ac+va+on in Go Credit: Vincent Bernat - “IntegraBon of

    a Go Service with systemd” - 2018
  50. Socket Ac+va+on in Go Credit: Vincent Bernat - “IntegraBon of

    a Go Service with systemd” - 2018
  51. $ go build 404.go $ systemd-socket-activate -l 8000 ./404 Listening

    on [::]:8000 as 3 $ curl '[::1]':8000 404 page not found $ curl '[::1]':8000 404 page not found
  52. Service Unit

  53. Socket Unit

  54. Graceful Shutdown

  55. Timer Units

  56. Timer Units

  57. This talk only scratches the surface of the capabiliGes of

    systemd
  58. THANK YOU!

  59. References • https://freedesktop.org/wiki/Software/systemd/ • https://github.com/jen20/hashidays-nyc • https://github.com/hashicorp/consul/pull/3164 • https://vincent.bernat.im/en/blog/2018- systemd-golang-socket-activation