{"id":15013964,"url":"https://github.com/voxpupuli/puppet-systemd","last_synced_at":"2025-05-15T03:05:04.341Z","repository":{"id":23225372,"uuid":"26582723","full_name":"voxpupuli/puppet-systemd","owner":"voxpupuli","description":"Puppet module to manage systemd","archived":false,"fork":false,"pushed_at":"2025-04-11T09:56:39.000Z","size":1383,"stargazers_count":56,"open_issues_count":15,"forks_count":148,"subscribers_count":47,"default_branch":"master","last_synced_at":"2025-04-14T01:04:49.784Z","etag":null,"topics":["archlinux-puppet-module","centos-puppet-module","debian-puppet-module","fedora-puppet-module","gentoo-puppet-module","hacktoberfest","linux-puppet-module","oraclelinux-puppet-module","puppet","redhat-puppet-module","sles-puppet-module","ubuntu-puppet-module"],"latest_commit_sha":null,"homepage":"https://forge.puppet.com/puppet/systemd","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/voxpupuli.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":".github/CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"open_collective":"vox-pupuli","github":"voxpupuli"}},"created_at":"2014-11-13T10:28:28.000Z","updated_at":"2025-04-11T09:56:40.000Z","dependencies_parsed_at":"2023-09-24T10:28:05.182Z","dependency_job_id":"68aa43b8-7fcb-4f61-af61-7bfb2cef3d8e","html_url":"https://github.com/voxpupuli/puppet-systemd","commit_stats":{"total_commits":623,"total_committers":94,"mean_commits":6.627659574468085,"dds":0.7897271268057785,"last_synced_commit":"58f0075f6926e3efec647f1f4d525e9ed1ad006a"},"previous_names":["camptocamp/puppet-systemd"],"tags_count":69,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/voxpupuli%2Fpuppet-systemd","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/voxpupuli%2Fpuppet-systemd/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/voxpupuli%2Fpuppet-systemd/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/voxpupuli%2Fpuppet-systemd/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/voxpupuli","download_url":"https://codeload.github.com/voxpupuli/puppet-systemd/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248804804,"owners_count":21164134,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["archlinux-puppet-module","centos-puppet-module","debian-puppet-module","fedora-puppet-module","gentoo-puppet-module","hacktoberfest","linux-puppet-module","oraclelinux-puppet-module","puppet","redhat-puppet-module","sles-puppet-module","ubuntu-puppet-module"],"created_at":"2024-09-24T19:45:00.535Z","updated_at":"2025-04-14T01:05:02.608Z","avatar_url":"https://github.com/voxpupuli.png","language":"Ruby","funding_links":["https://opencollective.com/vox-pupuli","https://github.com/sponsors/voxpupuli"],"categories":[],"sub_categories":[],"readme":"# Systemd\n\n[![Build Status](https://github.com/voxpupuli/puppet-systemd/workflows/CI/badge.svg)](https://github.com/voxpupuli/puppet-systemd/actions?query=workflow%3ACI)\n[![Release](https://github.com/voxpupuli/puppet-systemd/actions/workflows/release.yml/badge.svg)](https://github.com/voxpupuli/puppet-systemd/actions/workflows/release.yml)\n[![Puppet Forge](https://img.shields.io/puppetforge/v/puppet/systemd.svg)](https://forge.puppetlabs.com/puppet/systemd)\n[![Puppet Forge - downloads](https://img.shields.io/puppetforge/dt/puppet/systemd.svg)](https://forge.puppetlabs.com/puppet/systemd)\n[![Puppet Forge - endorsement](https://img.shields.io/puppetforge/e/puppet/systemd.svg)](https://forge.puppetlabs.com/puppet/systemd)\n[![Puppet Forge - scores](https://img.shields.io/puppetforge/f/puppet/systemd.svg)](https://forge.puppetlabs.com/puppet/systemd)\n[![puppetmodule.info docs](http://www.puppetmodule.info/images/badge.png)](http://www.puppetmodule.info/m/puppet-systemd)\n[![Apache-2 License](https://img.shields.io/github/license/voxpupuli/puppet-systemd.svg)](LICENSE)\n[![Donated by Camptocamp](https://img.shields.io/badge/donated%20by-camptocamp-fb7047.svg)](#transfer-notice)\n\n## Overview\n\nThis module declares exec resources to create global sync points for reloading systemd.\n\n### Version 2 and newer of the module don't work with Hiera 3! You need to migrate your existing Hiera setup to Hiera 5\n\n## Usage and examples\n\nThere are two ways to use this module.\n\n### unit files\n\nLet this module handle file creation.\n\n```puppet\nsystemd::unit_file { 'foo.service':\n  source =\u003e \"puppet:///modules/${module_name}/foo.service\",\n}\n~\u003e service { 'foo':\n  ensure =\u003e 'running',\n}\n```\n\nThis is equivalent to:\n\n```puppet\nfile { '/etc/systemd/system/foo.service':\n  ensure =\u003e file,\n  owner  =\u003e 'root',\n  group  =\u003e 'root',\n  mode   =\u003e '0644',\n  source =\u003e \"puppet:///modules/${module_name}/foo.service\",\n}\n~\u003e service { 'foo':\n  ensure =\u003e 'running',\n}\n```\n\nYou can also use this module to more fully manage the new unit. This example deploys the unit, reloads systemd and then enables and starts it.\n\n```puppet\nsystemd::unit_file { 'foo.service':\n  content =\u003e file(\"${module_name}/foo.service\"),\n  enable  =\u003e true,\n  active  =\u003e true,\n}\n```\n\nIf you're using \"template\" units (those with a `@` in it), you can\nsimply enable an instance of the template with a `service` resource. This, for example, will\nenable the `foo@bar` service unit, based on the `foo@` template:\n\n```puppet\nsystemd::unit_file { 'foo@.service':\n  content =\u003e file(\"${module_name}/foo@.service\"),\n  enable  =\u003e false,\n  active  =\u003e false,\n}\nservice { 'foo@bar.service':\n  ensure =\u003e true,\n  enable =\u003e true,\n}\n```\n\n### unit files from parameters\n\nCreate a unit file from parameters\n\n```puppet\nsystemd::manage_unit { 'myrunner.service':\n  unit_entry    =\u003e {\n    'Description' =\u003e 'My great service',\n  },\n  service_entry =\u003e {\n    'Type'      =\u003e 'oneshot',\n    'ExecStart' =\u003e '/usr/bin/doit.sh',\n  },\n  install_entry =\u003e {\n    'WantedBy' =\u003e 'multi-user.target',\n  },\n  enable        =\u003e true,\n  active        =\u003e true,\n}\n```\n\nThe parameters `unit_entry`, `service_entry` and `install_entry` populate the\n`[Unit]`, `[Service]` and `[Install]` sections of the generated unit file.\n\nSimilarly units can be created from hiera yaml files\n\n```yaml\nsystemd::manage_units:\n  myservice.service:\n    unit_entry:\n      Description: My Customisation\n    service_entry:\n      CPUWeight: 2000\n```\n\n### drop-in files\n\nDrop-in files are used to add or alter settings of a unit without modifying the\nunit itself. As for the unit files, the module can handle the file and\ndirectory creation:\n\n```puppet\nsystemd::dropin_file { 'foo.conf':\n  unit   =\u003e 'foo.service',\n  source =\u003e \"puppet:///modules/${module_name}/foo.conf\",\n}\n~\u003e service { 'foo':\n  ensure =\u003e 'running',\n}\n```\n\nThis is equivalent to:\n\n```puppet\nfile { '/etc/systemd/system/foo.service.d':\n  ensure =\u003e directory,\n  owner  =\u003e 'root',\n  group  =\u003e 'root',\n}\n\nfile { '/etc/systemd/system/foo.service.d/foo.conf':\n  ensure =\u003e file,\n  owner  =\u003e 'root',\n  group  =\u003e 'root',\n  mode   =\u003e '0644',\n  source =\u003e \"puppet:///modules/${module_name}/foo.conf\",\n}\n~\u003e service { 'foo':\n  ensure =\u003e 'running',\n}\n```\n\ndropin-files can also be generated via hiera:\n\n```yaml\nsystemd::dropin_files:\n  my-foo.conf:\n    unit: foo.service\n    source: puppet:///modules/${module_name}/foo.conf\n```\n\n### drop-in files from parameters\n\n```puppet\nsystemd::manage_dropin { 'myconf.conf':\n  ensure        =\u003e present,\n  unit          =\u003e 'myservice.service',\n  service_entry =\u003e {\n    'Type'      =\u003e 'oneshot',\n    'ExecStart' =\u003e ['', '/usr/bin/doit.sh'],\n  },\n}\n```\n\nDropins can also be created similarly via yaml\n\n```yaml\nsystemd::manage_dropins:\n  myconf.conf:\n    ensure: present\n    unit: myservice.service\n    service_entry:\n      Type: oneshot\n      ExecStart:\n        - ''\n        - '/usr/bin/doit.sh'\n```\n\nThe filename of the drop in. The full path is determined using the path, unit and this filename.\n\n### modules-load.d\n\nCreate a file entry for modules-loads directory and start\n`systemd-modules-load.service`\n\n```puppet\nsystemd::modules_load { 'impi.conf':\n  content =\u003e \"ipmi\\n\",\n}\n```\n\n### tmpfiles\n\nLet this module handle file creation and systemd reloading\n\n```puppet\nsystemd::tmpfile { 'foo.conf':\n  source =\u003e \"puppet:///modules/${module_name}/foo.conf\",\n}\n```\n\nOr handle file creation yourself and trigger systemd.\n\n```puppet\ninclude systemd::tmpfiles\n\nfile { '/etc/tmpfiles.d/foo.conf':\n  ensure =\u003e file,\n  owner  =\u003e 'root',\n  group  =\u003e 'root',\n  mode   =\u003e '0644',\n  source =\u003e \"puppet:///modules/${module_name}/foo.conf\",\n}\n~\u003e Class['systemd::tmpfiles']\n```\n\n### timer units\n\nCreate a systemd timer unit and a systemd service unit to execute from\nthat timer\n\nThe following will create a timer unit and a service unit file.\nWhen `active` and `enable` are set to `true` the puppet service `runoften.timer` will be\ndeclared, started and enabled.\n\n```puppet\nsystemd::timer { 'runoften.timer':\n  timer_source   =\u003e \"puppet:///modules/${module_name}/runoften.timer\",\n  service_source =\u003e \"puppet:///modules/${module_name}/runoften.service\",\n  active         =\u003e true,\n  enable         =\u003e true,\n}\n```\n\nA trivial daily run.\nIn this case enable and active are both unset and so the service `daily.timer`\nis not declared by the `systemd::timer` type.\n\n```puppet\n$_timer = @(EOT)\n[Timer]\nOnCalendar=daily\nRandomizedDelaySec=1d\nEOT\n\n$_service = @(EOT)\n[Service]\nType=oneshot\nExecStart=/usr/bin/touch /tmp/file\nEOT\n\nsystemd::timer { 'daily.timer':\n  timer_content   =\u003e $_timer,\n  service_content =\u003e $_service,\n}\n\nservice { 'daily.timer':\n  ensure    =\u003e running,\n  subscribe =\u003e Systemd::Timer['daily.timer'],\n}\n```\n\nIf neither `service_content` or `service_source` are specified then no\nservice unit will be created.\n\nThe service unit name can also be specified.\n\n```puppet\n$_timer = @(EOT)\n[Timer]\nOnCalendar=daily\nRandomizedDelaySec=1d\nUnit=touch-me-today.service\nEOT\n\n$_service = @(EOT)\n[Service]\nType=oneshot\nExecStart=/usr/bin/touch /tmp/file\nEOT\n\nsystemd::timer { 'daily.timer':\n  timer_content   =\u003e $_timer,\n  service_unit    =\u003e 'touch-me-today.service',\n  service_content =\u003e $_service,\n  active          =\u003e true,\n  enable          =\u003e true,\n}\n```\n\n### service limits\n\nIt's possible to ensure soft and hard limits on various resources for executed processes.\nPreviously `systemd::service_limits` was provided, but this is deprecated and will be removed in the next version.\n\n```puppet\nsystemd::service_limits { 'foo.service':\n  limits =\u003e {\n    'LimitNOFILE' =\u003e 8192,\n    'LimitNPROC'  =\u003e 16384,\n  }\n}\n```\n\nThe replacement is to use the `systemd::manage_dropin` defined type directly.\nTo migrate from the above example, use the following:\n\n```puppet\nsystemd::manage_dropin { 'foo.service-90-limits.conf':\n  unit            =\u003e 'foo.service',\n  filename        =\u003e '90-limits.conf',\n  service_entry   =\u003e {\n    'LimitNOFILE' =\u003e 8192,\n    'LimitNPROC'  =\u003e 16384,\n  },\n}\n```\n\n\n### machine-info (hostnamectl)\n\nYou can set elements of `/etc/machine-info` via the `machine_info_settings` parameter.  These values are read by `hostnamectl`.\n\nTo manage these, you'll need to add an additional module, [augeasproviders\\_shellvar](https://forge.puppet.com/modules/herculesteam/augeasproviders_shellvar), to your environment.\n\n### Daemon reloads\n\nSystemd caches unit files and their relations. This means it needs to reload, typically done via `systemctl daemon-reload`. Since Puppet 6.1.0 ([PUP-3483](https://tickets.puppetlabs.com/browse/PUP-3483)) takes care of this by calling `systemctl show $SERVICE -- --property=NeedDaemonReload` to determine if a reload is needed. Typically this works well and removes the need for `systemd::systemctl::daemon_reload` as provided prior to camptocamp/systemd 3.0.0. This avoids common circular dependencies.\n\nIt does contain a workaround for [PUP-9473](https://tickets.puppetlabs.com/browse/PUP-9473) but there's no guarantee that this works in every case.\n\n### network\n\nsystemd-networkd is able to manage your network configuration. We provide a\ndefined resource which can write the interface configurations. systemd-networkd\nneeds to be restarted to apply the configs. The defined resource can do this\nfor you:\n\n```puppet\nsystemd::network { 'eth0.network':\n  source          =\u003e \"puppet:///modules/${module_name}/eth0.network\",\n  restart_service =\u003e true,\n}\n```\n\n### Services\n\nThe default target is managed via the `default_target` parameter.  If this is left at its default value (`undef`), the default-target will be unmanaged by puppet.\n\nSystemd provides multiple services. Currently you can manage `systemd-resolved`,\n`systemd-timesyncd`, `systemd-networkd`, `systemd-journald`, `systemd-coredump`\nand `systemd-logind`\nvia the main class:\n\n```puppet\nclass { 'systemd':\n  manage_resolved  =\u003e true,\n  manage_networkd  =\u003e true,\n  manage_timesyncd =\u003e true,\n  manage_journald  =\u003e true,\n  manage_udevd     =\u003e true,\n  manage_logind    =\u003e true,\n  manage_coredump  =\u003e true,\n}\n```\n\n$manage_networkd is required if you want to reload it for new\n`systemd::network` resources. Setting $manage_resolved will also manage your\n`/etc/resolv.conf`.\n\nWhen configuring `systemd::resolved` you could set `use_stub_resolver` to false (default) to use a *standard* `/etc/resolved.conf`, or you could set it to `true` to use the local resolver provided by `systemd-resolved`.\n\nSystemd introduced `DNS Over TLS` in release 239. Currently three states are supported `yes` (since systemd 243), `opportunistic` (true) and `no` (false, default). When enabled with `yes` or `opportunistic` `systemd-resolved` will start a TCP-session to a DNS server with `DNS Over TLS` support. When enabled with `yes` (strict mode), queries will fail if the configured DNS servers do not support `DNS Over TLS`. Note that there will be no host checking for `DNS Over TLS` due to missing implementation in `systemd-resolved`.\n\nStopping `systemd-resolved` once running can be problematic and care should be taken.\n\n```puppet\nclass { 'systemd':\n  manage_resolved =\u003e true,\n  resolved_ensure =\u003e false,\n}\n```\n\nwill stop the service and should also copy `/run/systemd/resolve/resolv.conf` to `/etc/resolve.conf`.\n\n- Writing your own file to `/etc/resolv.conf` is also possible.\n\nIt is possible to configure the default ntp servers in `/etc/systemd/timesyncd.conf`:\n\n```puppet\nclass { 'systemd':\n  manage_timesyncd    =\u003e true,\n  ntp_server          =\u003e ['0.pool.ntp.org', '1.pool.ntp.org'],\n  fallback_ntp_server =\u003e ['2.pool.ntp.org', '3.pool.ntp.org'],\n}\n```\n\nwhen `manage_systemd` is true any required sub package, e.g. `systemd-resolved` on CentOS 9 or Debian 12, will be installed. However configuration of\nsystemd-resolved will only occur on second puppet run after that installation.\n\nThis requires [puppetlabs-inifile](https://forge.puppet.com/puppetlabs/inifile), which is only a soft dependency in this module (you need to explicitly install it). Both parameters accept a string or an array.\n\n### Resource Accounting\n\nSystemd has support for different accounting option. It can track\nCPU/Memory/Network stats per process. This is explained in depth at [systemd-system.conf](https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html).\nThis defaults to off (default on most operating systems). You can enable this\nwith the `$manage_accounting` parameter. The module provides a default set of\nworking accounting options per operating system, but you can still modify them\nwith `$accounting`:\n\n```puppet\nclass { 'systemd':\n  manage_accounting =\u003e true,\n  accounting        =\u003e {\n    'DefaultCPUAccounting'    =\u003e 'yes',\n    'DefaultMemoryAccounting' =\u003e 'no',\n  }\n}\n```\n\n### journald configuration\n\nIt also allows you to manage journald settings. You can manage journald settings through setting the `journald_settings` parameter. If you want a parameter to be removed, you can pass its value as params.\n\n```yaml\n---\nsystemd::journald_settings:\n  Storage: auto\n  MaxRetentionSec: 5day\n  MaxLevelStore:\n    ensure: absent\n```\n\n### udevd configuration\n\nIt allows you to manage the udevd configuration.  You can set the udev.conf values via the `udev_log`, `udev_children_max`, `udev_exec_delay`, `udev_event_timeout`, `udev_resolve_names`, and `udev_timeout_signal` parameters.\n\nAdditionally you can set custom udev rules with the `udev_rules` parameter.\n\n```puppet\nclass { 'systemd':\n  manage_udevd =\u003e true,\n  udev_rules   =\u003e {\n    'example_raw.rules' =\u003e {\n      'rules' =\u003e [\n        'ACTION==\"add\", KERNEL==\"sda\", RUN+=\"/bin/raw /dev/raw/raw1 %N\"',\n        'ACTION==\"add\", KERNEL==\"sdb\", RUN+=\"/bin/raw /dev/raw/raw2 %N\"',\n      ],\n    },\n  },\n}\n```\n\nWith enabled `udev_reload` modified rules would be applied immediately by executing `udevadm control --reload-rules`.\n\n```yaml\n---\nsystemd::udev_reload: true\nsystemd::manage_udevd: true\nsystemd::udev_rules:\n  50-md.rules:\n    rules:\n      - 'SUBSYSTEM==\"block\", KERNEL==\"md*\", ACTION==\"change\", TEST==\"md/stripe_cache_size\", ATTR{md/stripe_cache_size}=\"4096\"'\n```\n\n### udev::rules configuration\n\nCustom udev rules can be defined for specific events.\n\n```yaml\nsystemd::udev::rule:\n  ensure: present\n  path: /etc/udev/rules.d\n  selinux_ignore_defaults: false\n  notify: \"Service[systemd-udevd]\"\n  rules:\n    - 'ACTION==\"add\", KERNEL==\"sda\", RUN+=\"/bin/raw /dev/raw/raw1 %N\"'\n    - 'ACTION==\"add\", KERNEL==\"sdb\", RUN+=\"/bin/raw /dev/raw/raw2 %N\"'\n```\n\n### oomd configuration\n\nThe `systemd-oomd` system can be configured.\n\n```puppet\nclass { 'systemd':\n  manage_oomd   =\u003e true,\n  oomd_ensure   =\u003e 'running'\n  oomd_settings =\u003e {\n    'SwapUsedLimit'                    =\u003e '90%',\n    'DefaultMemoryPressureLimit'       =\u003e '60%',\n    'DefaultMemoryPressureDurationSec' =\u003e 30,\n  }\n}\n```\n\n### coredump configuration\n\nThe `systemd-coredump` system can be configured.\n\n```puppet\nclass{'systemd':\n  manage_coredump    =\u003e true,\n  coredump_backtrace =\u003e true,\n  coredump_settings  =\u003e {\n    'Storage'         =\u003e 'external',\n    'Compress'        =\u003e 'yes',\n    'ProcessSizeMax'  =\u003e '2G',\n    'ExternalSizeMax' =\u003e '10G',\n    'JournalSizeMax'  =\u003e '20T',\n    'MaxUse'          =\u003e '1E',\n    'KeepFree'        =\u003e '1P',\n  }\n}\n```\n\n### logind configuration\n\nIt also allows you to manage logind settings. You can manage logind settings through setting the `logind_settings` parameter. If you want a parameter to be removed, you can pass its value as params.\n\n```yaml\nsystemd::logind_settings:\n  HandleSuspendKey: 'ignore'\n  KillUserProcesses: 'no'\n  RemoveIPC:\n    ensure: absent\n  UserTasksMax: 10000\n```\n\n### User linger\n\nA `loginctl_user` resource is available to manage user linger enablement:\n\n```puppet\nloginctl_user { 'foo':\n  linger =\u003e enabled,\n}\n```\n\nor as a hash via the `systemd::loginctl_users` parameter.\n\n### Systemd Escape Function\n\nPartially escape strings as `systemd-escape` command does.\n\nThis functions only escapes a subset of chars. Non-ASCII character will not escape.\n\n```puppet\n$result = systemd::escape('foo::bar/')\n```\n\n`$result` would be `foo::bar-`\n\nor path escape as if with `-p` option.\n\n```puppet\n$result = systemd::escape('/mnt/foobar/', true)\n```\n\n`$result` would be `mnt-foobar`.\n\n### Systemd Escape Function (uses systemd-escape)\n\nEscape strings call the `systemd-escape` command in the background.\n\nIt's highly recommend running the function as [deferred function](https://puppet.com/docs/puppet/6/deferring_functions.html) since it executes the command on the agent.\n\n```puppet\n$result = Deferred('systemd::systemd_escape', [\"foo::bar\"])\n```\n\n`$result` would be `foo::bar-`\n\nor path escape as if with `-p` option.\n\n```puppet\n$result = Deferred('systemd::systemd_escape', [\"/mnt/foo-bar/\", true])\n```\n\n`$result` would be `mnt-foo\\x2dbar`.\n\n## Tasks\n\n### systemd::systemctl_show\n\nReturns more parseable output then the standard service task from bolt itself.\n\nDefault property filter: `[\"ActiveState\", \"LoadState\", \"MainPID\", \"SubState\", \"UnitFileState\"]`\n\n#### output of standard task from bolt\n\n```text\nbolt task run service name=puppet.service action=status -t controller-0\n\nStarted on controller-0...\nFinished on controller-0:\n  {\n    \"status\": \"MainPID=686,LoadState=loaded,ActiveState=active\",\n    \"enabled\": \"enabled\"\n  }\n```\n\n#### output of systemd::systemctl_show\n\n```text\nbolt task run systemd::systemctl_show unit_name=puppet.service -t controller-0\n\nStarted on controller-0...\nFinished on controller-0:\n  {\n    \"MainPID\": \"686\",\n    \"LoadState\": \"loaded\",\n    \"ActiveState\": \"active\",\n    \"SubState\": \"running\",\n    \"UnitFileState\": \"enabled\"\n  }\n```\n\n## Deprecation Notices\n\nThe type `systemd::service_limits` is deprecated and `systemd::manage_dropin` or `systemd::dropin_file` should\nbe used instead.\n\n## Transfer Notice\n\nThis plugin was originally authored by [Camptocamp](http://www.camptocamp.com).\nThe maintainer preferred that Puppet Community take ownership of the module for future improvement and maintenance.\nExisting pull requests and issues were transferred over, please fork and continue to contribute here instead of Camptocamp.\n\nPreviously: [https://github.com/camptocamp/puppet-systemd]\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvoxpupuli%2Fpuppet-systemd","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fvoxpupuli%2Fpuppet-systemd","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvoxpupuli%2Fpuppet-systemd/lists"}