#869 Fixed dead links
Merged 5 years ago by ignatenkobrain. Opened 5 years ago by hiwkby.
Unknown source master  into  master

@@ -171,7 +171,7 @@

  

  ==== Hardware activation

  

- Hardware activation occurs when a service is installed but only turns on if a certain type of hardware is installed. Enabling of the service is normally done with a udev rule. At this time we do not have further guidance on how to write those udev rules. The service itself installs its `+.service+` files in the normal places and are installed by the normal Packaging:ScriptletSnippets#Systemd[ systemd scriptlets]. These services should never be enabled by the package as they will be enabled by udev.

+ Hardware activation occurs when a service is installed but only turns on if a certain type of hardware is installed. Enabling of the service is normally done with a udev rule. At this time we do not have further guidance on how to write those udev rules. The service itself installs its `+.service+` files in the normal places and are installed by the normal xref:Scriptlets.adoc#_systemd[systemd scriptlets]. These services should never be enabled by the package as they will be enabled by udev.

  

  ==== Socket activation

  
@@ -187,7 +187,7 @@

  

  However, socket activation can also be used to allow parallel startup of services. If a service supports systemd socket activation as described above and we additionally start it explicitly on boot, then systemd will start it but allow things that depend on it to startup at the same time. If the dependent service makes a request to the socket activatable service before it has come up, then systemd will cause the request to wait until the socket activatable service has come up and can process the request. To achieve this effect, the service must be socket activatable as described above, the `+.service+` file for the service needs to have a `+Wants=+` line for the `+.socket+`, and the service must autostart.

  

- Note that certain socket activated services (notably network listening ones) require FESCo approval - see Packaging:DefaultServices for details. Once you have permission, you can package the `+.socket+` file and use the systemd scriptlets that enable the service by default. You need to also check the `+.service+` file to make sure it has a `+Wants=+` entry on the `+.socket+` file as that ensures that starting the service will also inform systemd of the socket.

+ Note that certain socket activated services (notably network listening ones) require FESCo approval - see xref:DefaultServices.adoc[Packaging:DefaultServices] for details. Once you have permission, you can package the `+.socket+` file and use the systemd scriptlets that enable the service by default. You need to also check the `+.service+` file to make sure it has a `+Wants=+` entry on the `+.socket+` file as that ensures that starting the service will also inform systemd of the socket.

  

  ==== Timer activation

  
@@ -354,11 +354,11 @@

  

  === Unit files in spec file scriptlets

  

- Information on proper handling of unit files in spec file scriptlets can be found here: :Packaging:Scriptlets#Systemd

+ Information on proper handling of unit files in spec file scriptlets can be found here: xref:Scriptlets.adoc#_systemd[Packaging:Scriptlets#Systemd].

  

  === Tmpfiles.d

  

- tmpfiles.d is a service provided systemd in Fedora 15 and later for managing temporary files and directories for daemons. For more information on how to use Tmpfiles.d in Fedora Packages, please see: :Packaging:Tmpfiles.d

+ tmpfiles.d is a service provided systemd in Fedora 15 and later for managing temporary files and directories for daemons. For more information on how to use Tmpfiles.d in Fedora Packages, please see: xref:Tmpfiles.d.adoc[Packaging:Tmpfiles.d].

  

  === Why don't we....

  

Hello, this PR fixes markup errors that should be hyper links.

rebased onto 3e800ad

5 years ago

Pull-Request has been merged by ignatenkobrain

5 years ago
Metadata