Register
Login
Resources
Docs Blog Datasets Glossary Case Studies Tutorials & Webinars
Product
Data Engine LLMs Platform Enterprise
Pricing Explore
Connect to our Discord channel

Systemd.txt 24 KB

You have to be logged in to leave a comment. Sign In
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
  1. = Fedora systemd Services
  2. This document describes the guidelines for systemd services,
  3. for use and inclusion in Fedora packages.
  4. [#definitions]
  5. == Definitions
  6. Since systemd includes some concepts which are extensions of previous concepts,
  7. the following definitions may be useful:
  8. Service::
  9. A process or task executed and controlled by the init system
  10. (e.g. systemd).
  11. Traditional Service:: A service which is explicitly started or stopped,
  12. either by the init system at boot
  13. or manually by a superuser.
  14. In systemd, one of several types of service controlled by a `+.service+` file.
  15. Activated service::
  16. A service that is not (or not necessarily) started explicitly by the user
  17. but start when certain other events happen
  18. or certain state becomes true.
  19. Socket-activated Service::
  20. A service which is waiting for traffic across a socket
  21. before activating.
  22. In systemd, controlled by a `+.socket+` file.
  23. D-Bus service::
  24. A service which activates in response to a message from the D-Bus system bus.
  25. Unit file::
  26. The systemd equivalent of a SysV initscript.
  27. [#unit_files]
  28. == Unit Files
  29. Each package that contains software that wants/needs
  30. to start a traditional service at boot
  31. MUST have a systemd unit file.
  32. Ideally, systemd unit files are reusable across distributions
  33. and shipped with the upstream packages.
  34. Please consider working with upstream
  35. to integrate the systemd files you prepare in the upstream sources.
  36. Information for developers on how to integrate systemd support best with their build system
  37. you may find in
  38. https://www.freedesktop.org/software/systemd/man/daemon.html[daemon(8)].
  39. [#unit_files_naming]
  40. === Naming
  41. Unit files for traditional services have a naming scheme of `+foobar.service+`.
  42. When considering what basename to use,
  43. keep in mind that we'd like to use the same service names for software across distributions.
  44. We'd also like to ship the `+.service+` files in the upstream packages.
  45. These desires create a few guides for naming a unit file:
  46. * Follow upstream if they're already distributing a `+.service+` file
  47. and it's not likely to conflict with other packages.
  48. * Look at packages in other distros
  49. or talk with the maintainers of those packages and upstream
  50. to try to come up with a common name.
  51. * Unit files should be named after the software implementation that they support
  52. as opposed to the generic type of software.
  53. So, a good name would be `+apache-httpd.service+`
  54. and bad names would be `+httpd.service+` or `+apache.service+`
  55. as there are multiple httpd implementations
  56. and multiple projects produced by the apache foundation.
  57. For backwards compatibility
  58. you may also want to create a symlink from an older, name to the new name.
  59. In the above example, for instance,
  60. Fedora has always used `+httpd+` for the service.
  61. When creating the new `+apache-httpd.service+` file,
  62. also create a symlink named `+httpd.service+`
  63. that points at `+apache-httpd.service+`.
  64. Then end users that are used to using `+service httpd+`
  65. will have it continue to work.
  66. [#unit_files_basic_format]
  67. === Basic format
  68. [#unit_files_basic_format_unit]
  69. ==== [Unit]
  70. Every `+.service+` file must begin with a `+[Unit]+` section:
  71. ....
  72. [Unit]
  73. Description=A brief human readable string describing the service (not the .service file!)
  74. Documentation=man:foo.service(8) man:foo.conf(5) https://www.foo.org/docs/
  75. ....
  76. The `+Description=+` line must not exceed 80 characters,
  77. and must describe the service, and not the `+.service+` file.
  78. For example, "Apache Web Server" is a good description,
  79. but "Starts and Stops the Apache Web Server" is a bad one.
  80. [#unit_files_basic_format_unit_doc]
  81. ===== Documentation field
  82. Systemd has support for defining documentation in unit files
  83. via the `Documentation=` field.
  84. System administrators will be looking at the contents of the `+Documentation=+` field
  85. to determine what the service is,
  86. how to configure it,
  87. and where to locate additional documentation relating to the service.
  88. Accordingly, packagers are strongly encouraged
  89. to include any available sources in the `Documentation=` field
  90. which provide this information.
  91. If a man page or info page is present in the package,
  92. refer to it using `man:manpage` or `info:infofile` respectively.
  93. If the documentation is in plaintext, use `\file://path/to/file`.
  94. Lastly, if no local documentation exists in the package,
  95. but it exists at a URL,
  96. use the URL (with `https://`) in this field.
  97. Multiple URIs can be added to the `Documentation=` field,
  98. as a space separated list.
  99. For details on URI definitions and formatting,
  100. please refer to the `uri(7)` manpage (`man uri`).
  101. [#unit_files_basic_format_service]
  102. ==== [Service]
  103. Next, the `+.service+` file must have a `+[Service]+` section:
  104. ....
  105. [Service]
  106. Type=...
  107. ExecStart=...
  108. ExecReload=...
  109. ....
  110. The `+Type=+` setting is very important.
  111. For D-Bus services this should be `+dbus+`,
  112. for traditional services `+forking+` is usually a good idea,
  113. for services not offering any interfaces to other services `+simple+` is best.
  114. For "one-shot" scripts `+oneshot+` is ideal,
  115. often combined with `+RemainAfterExit=+`.
  116. See https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd.service(5)]
  117. for further discussion on the topic.
  118. Since `+simple+` is the default type,
  119. `+.service+` files which would normally set `+Type=simple+`
  120. may simply omit the `+Type+` line altogether.
  121. `+BusName=+` should be set for all services connecting to D-Bus.
  122. (i.e. it is a must for those where `+Type=dbus+`,
  123. but might make sense otherwise, too)
  124. Omit this option if your service does not take a name on the bus.
  125. `+ExecStart=+` is necessary for all services.
  126. This line defines the string that you would run to start the daemon,
  127. along with any necessary options.
  128. `+ExecReload=+` should be specified for all services supporting reload.
  129. It is highly recommended to add code here
  130. that synchronously reloads the configuration file here
  131. (i.e. `+/bin/kill -HUP $MAINPID+` is usually a poor choice,
  132. due to its asynchronous nature).
  133. Omit this option if your service does not support reloading.
  134. [#unit_files_basic_format_install]
  135. ==== [Install]
  136. Finally, the `+.service+` file should have an `+[Install]+` section:
  137. ....
  138. [Install]
  139. WantedBy=...
  140. ....
  141. The recommended parameters for `+WantedBy=+` are either
  142. `+graphical.target+` (services related to the graphical user interface)
  143. or `+multi-user.target+` (for everything else).
  144. When the user (or our scriptlets) invoke `+systemctl enable+`
  145. the service will be set to start in these targets.
  146. For more information regarding these options
  147. see https://www.freedesktop.org/software/systemd/man/systemd.unit.html[systemd.unit(5)]
  148. and https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd.service(5)].
  149. [#unit_files_env]
  150. === EnvironmentFiles and support for /etc/sysconfig files
  151. The `+EnvironmentFiles=+` line in the `+[Service]+` section of `+.service+` files
  152. is used to support loading environment variables that can be used in unit files.
  153. For instance,
  154. if your sysv-initscript used a file in `+/etc/sysconfig+` to set command line options,
  155. you can use `+EnvironmentFiles=+` like so:
  156. Example:
  157. ....
  158. [Service]
  159. Type=forking
  160. EnvironmentFile=-/etc/sysconfig/httpd
  161. ExecStart=httpd $OPTIONS
  162. ExecReload=httpd $OPTIONS -k restart
  163. ....
  164. You may then refer to variables set in the `+/etc/sysconfig/httpd+` file
  165. with `+${FOOBAR}+` and `+$FOOBAR+`,
  166. in the `+ExecStart=+` lines (and related lines).
  167. (`+${FOOBAR}+` expands the variable into one word,
  168. `+$FOOBAR+` splits up the variable value at whitespace into multiple words)
  169. The `+-+` on the `+EnvironmentFile=+` line
  170. ensures that no error messages is generated
  171. if the environment file does not exist.
  172. Since many of these files were optional in sysvinit,
  173. you should include the `+-+` when using this directive.
  174. [#unit_files_avoid]
  175. === Fields to avoid
  176. For most services,
  177. we do not want to use requirement dependencies in the `+[Unit]+` section,
  178. such as `+Requires=+` or `+Wants=+`.
  179. Instead exclusively use ordering dependencies:
  180. `+Before=+` and `+After=+`.
  181. This is used to implement loose coupling:
  182. if someone asks two services to start at the same time,
  183. systemd will properly order their startup
  184. but not make it strictly necessary to run one if the other is started.
  185. If you use a requirement dependency,
  186. use `+Wants=+` rather than `+Requires=+`,
  187. to make things a little bit more robust.
  188. If you use a requirement dependency
  189. in almost all cases you should also add an ordering dependency,
  190. as ordering and requirement dependencies are orthogonal in systemd.
  191. Here's an example of this common case:
  192. . A web application needs postgresql to store its data.
  193. . It is set to start `+After+` postgresql.
  194. On startup, the web application does not start until postgresql does.
  195. . Once running,
  196. the system administrator needs to restart postgresql due to a config tweak.
  197. . Since only `+After+` was used,
  198. the web application may be temporarily unable to serve some requests
  199. but it does not need to restart in order to serve pages
  200. after the database comes back up.
  201. Avoid referring to `+runlevelX.target+` units in all lines taking unit names
  202. (such as `+WantedBy+`),
  203. these are legacy names existing for compatibility with SysV only.
  204. Avoid `+Names=+` (in the `+[Unit]+` section).
  205. Usually it is a better idea to symlink an additional name in the file system.
  206. Note that a name listed in `+Names=+` is only useful
  207. when a service file is already loaded.
  208. However, systemd loads only the service files actually referred to
  209. in another loaded service,
  210. and uses the filenames during the search.
  211. Hence a name in `+Names=+` is not useful as a search key,
  212. but a symlink in the file system is.
  213. Also do not put a (redundant) `+Names=foobar.service+` line
  214. into a file called `+foobar.service+`.
  215. We want to keep our service files short.
  216. Unit files should avoid using `+StandardOutput=+` or `+StandardError=+`.
  217. The default is the right choice for almost all cases,
  218. and using the default allows users to change global defaults
  219. in /etc/systemd/system.conf.
  220. [#unit_files_example]
  221. === Example Unit file
  222. This is an example systemd unit `+.service+` file for ABRT:
  223. ....
  224. [Unit]
  225. Description=ABRT Automated Bug Reporting Tool
  226. [Service]
  227. Type=dbus
  228. BusName=com.redhat.abrt
  229. ExecStart=abrtd -d -s
  230. [Install]
  231. WantedBy=multi-user.target
  232. ....
  233. [#activation]
  234. == Activation
  235. Systemd allows for the following forms of activated services:
  236. xref:#activation_hardware[Hardware activation],
  237. xref:#activation_socket[Socket activation],
  238. xref:#activation_timer[Timer activation],
  239. and xref:#activation_dbus[DBus activation].
  240. [#activation_hardware]
  241. === Hardware activation
  242. Hardware activation occurs when a service is installed
  243. but only turns on if a certain type of hardware is installed.
  244. Enabling of the service is normally done with a udev rule.
  245. At this time we do not have further guidance on how to write those udev rules.
  246. The service itself installs its `+.service+` files in the normal places
  247. and are installed by the normal xref:Scriptlets.adoc#_systemd[systemd scriptlets]. These services should never be enabled by the package
  248. as they will be enabled by udev.
  249. [#activation_socket]
  250. === Socket activation
  251. Socket activation occurs when a service allows systemd to listen for connections to a specific socket
  252. and, when systemd receives a connection on that socket,
  253. it starts the service.
  254. To do this, the upstream source needs to have some minor coding work
  255. to let systemd listen for connections on the socket
  256. and there needs to be a `+.socket+` file in `+%{_lib}/systemd/system/+`
  257. that tells systemd to listen to that socket
  258. and what to start when a connection is received.
  259. This is similar in function to inetd
  260. and some, but not all, services coded to work with inetd
  261. will work with socket activation.
  262. However, socket activation can also be used to allow parallel startup of services.
  263. If a service supports systemd socket activation as described above
  264. and we additionally start it explicitly on boot,
  265. then systemd will start it
  266. but allow things that depend on it to startup at the same time.
  267. If the dependent service makes a request to the socket activatable service before it has come up,
  268. then systemd will cause the request to wait
  269. until the socket activatable service has come up and can process the request.
  270. To achieve this effect,
  271. the service must be socket activatable as described above,
  272. the `+.service+` file for the service needs to have a `+Wants=+` line for the `+.socket+`,
  273. and the service must autostart.
  274. Note that certain socket activated services
  275. (notably network listening ones)
  276. require FESCo approval —
  277. see xref:DefaultServices.adoc[Default Services] for details.
  278. Once you have permission,
  279. you can package the `+.socket+` file
  280. and use the systemd scriptlets that enable the service by default.
  281. You need to also check the `+.service+` file
  282. to make sure it has a `+Wants=+` entry on the `+.socket+` file
  283. as that ensures that starting the service will also inform systemd of the socket.
  284. [#activation_timer]
  285. === Timer activation
  286. All packages with timed execution which already depend on systemd
  287. (for example because they contain systemd units)
  288. must use timer units instead of cron jobs,
  289. with no dependency or requirements on a crontab.
  290. Packages which do not already depend or require systemd must not use timer units
  291. but instead depend and have requirement on crontabs,
  292. to avoid introducing unnecessary new dependencies on systemd directly.
  293. [#activation_dbus]
  294. === DBus activation
  295. In order to allow parallel startup of a D-Bus service and its consumers
  296. it is essential that D-Bus services can be bus activated
  297. and the D-Bus activation request is forwarded from the D-Bus system bus to systemd
  298. so that you end up with only a single instance of the service,
  299. even if a service is triggered by both boot-up and activation.
  300. If historically your D-Bus service was not bus-activated
  301. but started via a SysV init script,
  302. it should be updated to use bus activation.
  303. This may be implemented
  304. by dropping a D-Bus `+.service+` file in `+/usr/share/dbus-1/system-services/+`
  305. and use the `+SystemdService=+` directive therein
  306. to redirect the activation to systemd.
  307. Here's an example for a D-Bus bus-activable service.
  308. The ConsoleKit bus activation file
  309. `+/usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service+`:
  310. ....
  311. [D-BUS Service]
  312. Name=org.freedesktop.ConsoleKit
  313. Exec=console-kit-daemon --no-daemon
  314. User=root
  315. SystemdService=console-kit-daemon.service
  316. ....
  317. And the matching systemd unit file
  318. /usr/lib/systemd/system/console-kit-daemon.service:
  319. ....
  320. [Unit]
  321. Description=Console Manager
  322. [Service]
  323. Type=dbus
  324. BusName=org.freedesktop.ConsoleKit
  325. ExecStart=console-kit-daemon --no-daemon
  326. ....
  327. As you can see `+SystemdService=+` is used in the D-Bus activation file
  328. to bind the systemd service to the D-Bus service.
  329. Traditionally,
  330. bus activated D-Bus services could not be disabled
  331. without uninstalling them entirely.
  332. systemd allows you to disable services
  333. by making D-Bus invoke an alias systemd service name
  334. (that can be created or removed to enable/disable activation)
  335. as an intermediary for the real service.
  336. You can easily implement disabling
  337. by directing the D-Bus service to an alias name of the real service file
  338. (in the filesystem this shows up as a symlink
  339. placed in `+/etc/systemd/system+` to the real service file).
  340. This alias is then controlled via `+systemctl enable+` and `+systemctl disable+`.
  341. It is a good idea
  342. (though technically not necessary)
  343. to name this alias name after the D-Bus bus name of the service,
  344. prefixed with `+dbus-+`.
  345. Example for Avahi, a service that the admin might need to disable:
  346. set `+SystemdService=dbus-org.freedesktop.Avahi.service+`
  347. instead of `+SystemdService=avahi-daemon.service+` in the D-Bus activation file,
  348. and then make `+dbus-org.freedesktop.Avahi.service+` an optional alias of avahi-daemon.service
  349. that can be controlled via the `+Alias=+` directive
  350. in the `+[Install]+` section of the systemd service file.
  351. This directive is then read by `+systemctl enable+` and `+systemctl disable+`
  352. to create resp. remove a symlink
  353. to make the service available resp. unavailable under this additional name.
  354. A full example for the Avahi case:
  355. Here is the D-Bus .service file for Avahi
  356. (`+/usr/share/dbus-1/system-services/org.freedesktop.Avahi.service+`):
  357. ....
  358. [D-BUS Service]
  359. Name=org.freedesktop.Avahi
  360. SystemdService=dbus-org.freedesktop.Avahi.service
  361. # This service should not be bus activated if systemd isn't running,
  362. # so that activation won't conflict with the init script startup.
  363. Exec=false
  364. ....
  365. Here is the Avahi systemd unit `+.service+` file
  366. (`+/usr/lib/systemd/system/avahi-daemon.service+`):
  367. ....
  368. [Unit]
  369. Description=Avahi mDNS/DNS-SD Stack
  370. Requires=avahi-daemon.socket
  371. [Service]
  372. Type=dbus
  373. BusName=org.freedesktop.Avahi
  374. ExecStart=avahi-daemon -s
  375. ExecReload=avahi-daemon -r
  376. NotifyAccess=main
  377. [Install]
  378. WantedBy=multi-user.target
  379. Also=avahi-daemon.socket
  380. Alias=dbus-org.freedesktop.Avahi.service
  381. ....
  382. The `+Alias=+` line ensures
  383. that the existance of the `+/etc/systemd/system/dbus-org.freedesktop.Avahi.service+` symlink
  384. can be controlled by `+systemctl enable+` and `+systemctl disable+`.
  385. Note that the creation/removal of the alias symlinks
  386. should be done with `+systemctl enable+` and `+systemctl disable+` only.
  387. You should not create these symlinks manually.
  388. In general,
  389. it is also recommended to supply native systemd units
  390. for all services that are already bus activatable,
  391. so that these services can be controlled and supervised centrally
  392. like any other service with tools such as systemctl.
  393. A similar logic like the one shown above should apply.
  394. See the D-Bus documentation for more information about bus activation:
  395. https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services
  396. [#automatic_restart]
  397. == Automatic restarting
  398. If you package a long-running service,
  399. please consider enabling systemd's automatic restart feature for it,
  400. to improve reliability
  401. by making sure the system automatically attempts recovering a failing daemon.
  402. Please use
  403. ....
  404. [Service]
  405. ...
  406. Restart=on-failure
  407. ....
  408. or
  409. ....
  410. [Service]
  411. ...
  412. Restart=on-abnormal
  413. ....
  414. in your unit's `+.service+` file for this.
  415. The former will tell systemd to restart the daemon as soon as it fails
  416. regardless of the precise reason.
  417. It's a good choice for most long-running services.
  418. Some daemons require a way to escape constant restarting
  419. by exiting with any non-zero exit code.
  420. For those services use `+Restart=on-abnormal+`,
  421. which will still restart the daemon when it fails "abnormally",
  422. on unclean signal,
  423. core dump,
  424. timeout
  425. or watchdog exits,
  426. but not on unclean exit codes.
  427. It is recommended to to enable automatic restarts for all long-running services,
  428. but which setting is the right one,
  429. and whether it is useful at all
  430. depends on the specific service.
  431. Please consult the
  432. https://www.freedesktop.org/software/systemd/man/systemd.service.html[systemd.service(5)] man page
  433. for more information on the various settings.
  434. [#private]
  435. == Private devices and networking
  436. If you package a long-running system service,
  437. please consider enabling systemd's `+PrivateDevices=+` and `+PrivateNetwork=+` settings for it,
  438. in order to improve security and minimize the attack surface.
  439. When `+PrivateDevices=yes+` is set in the `+[Service]+` section
  440. of a systemd service unit file,
  441. the processes run for the service will run in a private file system namespace
  442. where `+/dev+` is replaced by a minimal version
  443. that only includes the device nodes
  444. `+/dev/null+`,
  445. `+/dev/zero+`,
  446. `+/dev/full+`,
  447. `+/dev/urandom+`,
  448. `+/dev/random+`,
  449. `+/dev/tty+`
  450. as well as the submounts
  451. `+/dev/shm+`,
  452. `+/dev/pts+`,
  453. `+/dev/mqueue+`,
  454. `+/dev/hugepages+`,
  455. and the `+/dev/stdout+`, `+/dev/stderr+`, `+/dev/stdin+` symlinks.
  456. No device nodes for physical devices will be included, however.
  457. Furthermore, the CAP_MKNOD capability is removed.
  458. Finally, the `+devices+` cgroup controller is used
  459. to ensure that no access to device nodes except the listed ones is possible.
  460. This is an efficient way to take away physical device access for services,
  461. thus minimizing the attack surface.
  462. When `+PrivateNetwork=yes+` is set in the `+[Service]+` section
  463. of a systemd service unit file,
  464. the processes run for the service will run in a private network namespace
  465. whith a private loopback network interface,
  466. and no other network devices.
  467. Network communication between host and service can not be initiated.
  468. This is an efficient way to take away network access for services,
  469. thus minimizing the attack surface.
  470. By default both switches default to `+no+`.
  471. Note that `+PrivateDevices=yes+` should not be used for:
  472. * Services that actually require physical device access
  473. * Services which may be used to execute arbitrary user or administrator supplied programs
  474. (such as cron, ...).
  475. We shouldn't limit what people can do with these services.
  476. * This option creates a new file system namespace
  477. where mount/umount propagation is turned off back into the host.
  478. This means that mounts made by the service will stay private to the service.
  479. Thus this option should not be used by services which shall be able to establish mounts in the host.
  480. Note that `+PrivateNetwork=yes+` should not be used for:
  481. * Services that actually require network access
  482. (with the exception of daemons only needing socket activation)
  483. * Services which may be used to execute arbitrary user or administrator supplied programs.
  484. (see above)
  485. * Services which might need to resolve non-system user and group names.
  486. Since on some setups resolving non-system users might require network access to an LDAP or NIS server,
  487. enabling this option on might break resolving of these user names.
  488. Note however that system users/groups are always resolvable
  489. even without network access.
  490. Hence it is safe to enable this option for daemons which just need to resolve their own system user or group name.
  491. * This also disconnects the AF_UNIX abstract namespace from the host
  492. (In case you wonder what this refers to:
  493. sockets listed in `+/proc/net/unix+` that start with an `+@+`
  494. are in the abstract namespace,
  495. those which start in `+/+` are in the file system namespace).
  496. This means that services which listen or connect to AF_UNIX sockets in the abstract namespaces might break.
  497. AF_UNIX sockets in the file system continue to work correctly even with `+PrivateNetwork?=yes+`.
  498. We strongly recommend anyway to stop using abstract namespace AF_UNIX sockets,
  499. as they bring very little benefit these days.
  500. If your package uses them
  501. please consider moving them into the file system
  502. into a subdirectory in `+/run+` (system services)
  503. or `+$XDG_RUNTIME_DIR+` (user services).
  504. * This also disconnects the AF_NETLINK and AF_AUDIT socket families from the host.
  505. For services requiring auditing,
  506. that need to subscribe to network configuration changes,
  507. or want to subscribe to hardware devices coming and going (udev)
  508. `+PrivateNetwork?=yes+` cannot be used hence.
  509. For further details see the
  510. https://www.freedesktop.org/software/systemd/man/systemd.exec.html[systemd.exec(5)] man page.
  511. [#packaging]
  512. == Packaging
  513. [#packaging_filesystem]
  514. === Filesystem locations
  515. Packages with systemd unit files *must* put them into `+%{_unitdir}+`
  516. or `+%{_userunitdir}+`.
  517. `+%{_unitdir}+` evaluates to `+/usr/lib/systemd/system+` on all Fedora systems
  518. and `+%{_userunitdir}%+` evaluates to `+/usr/lib/systemd/user+`.
  519. Unit files are architecture independent
  520. (hence, not `+%{_lib}+`)
  521. and needed early in the boot process.
  522. Most systemd service files should use `+%{_unitdir}+`.
  523. However, if the service runs as part of a user session
  524. (e.g. pipewire services, gpg-agent, tracker, etc),
  525. use `+%{_userunitdir}+` instead.
  526. Please note that in order for the `+%{_unitdir}+` or `+%{_userunitdir}+` macro to exist,
  527. your package must have:
  528. ....
  529. BuildRequires: systemd-rpm-macros
  530. ....
  531. [#packaging_files_section]
  532. === %files section
  533. Systemd unit `+.service+` files must not be marked as `+%config+` files.
  534. [#packaging_unit_files_in_scriptlets]
  535. === Unit files in spec file scriptlets
  536. Information on proper handling of unit files in spec file scriptlets
  537. can be found here:
  538. xref:Scriptlets.adoc#_systemd[Scriptlets#Systemd].
  539. [#packaging_tmpfiles_d]
  540. === Tmpfiles.d
  541. tmpfiles.d is a service provided systemd
  542. for managing temporary files and directories for daemons.
  543. For more information on how to use Tmpfiles.d in Fedora Packages,
  544. please see:
  545. xref:Tmpfiles.d.adoc[Tmpfiles.d].
  546. [#why_dont_we]
  547. == Why don't we....
  548. * Start the service after installation?
  549. Installations can be in changeroots,
  550. in an installer context,
  551. or in other situations where you don't want the services autostarted.
Tip!

Press p or to see the previous file or, n or to see the next file

Comments

Loading...