2 files changed, 22 insertions, 7 deletions
diff --git a/docs/tutorials/basic_networking.md b/docs/tutorials/basic_networking.md
index 0a6034e7a..05c3a731e 100644
--- a/docs/tutorials/basic_networking.md
+++ b/docs/tutorials/basic_networking.md
@@ -32,7 +32,7 @@ port mapping.  Depending on the firewall implementation, we have observed firewa
 ports being opened automatically due to running a container with a port mapping (for
 example).  If container traffic does not seem to work properly, check the firewall
 and allow traffic on ports the container is using. A common problem is that
-reloading the firewall deletes the cni iptables rules resulting in a loss of
+reloading the firewall deletes the cni/netavark iptables rules resulting in a loss of
 network connectivity for rootful containers. Podman v3 provides the podman
 network reload command to restore this without having to restart the container.
 
@@ -83,7 +83,7 @@ users.  But as of Podman version 4.0, rootless users can also use netavark.
 The user experience of rootless netavark is very akin to a rootful netavark, except that
 there is no default network configuration provided.  You simply need to create a
 network, and the one will be created as a bridge network. If you would like to switch from
-CNI networking to netvaark, you must issue the `podman system reset --force` command.
+CNI networking to netavark, you must issue the `podman system reset --force` command.
 This will delete all of your images, containers, and custom networks.
 
 ```
@@ -177,7 +177,7 @@ address, you should continue to use CNI instead of netavark.
 
 ```
 $ sudo podman network create -d macvlan -o parent=eth0 webnetwork
-/etc/cni/net.d/webnetwork.conflist
+webnetwork
 ```
 The next step is to ensure that the DHCP CNI plugin is running.  This plugin facilitates
 the DHCP lease from the network.
diff --git a/docs/tutorials/socket_activation.md b/docs/tutorials/socket_activation.md
index 9b4b02b81..f4ad5aefd 100644
--- a/docs/tutorials/socket_activation.md
+++ b/docs/tutorials/socket_activation.md
@@ -19,7 +19,7 @@ The architecture looks like this
 
 ``` mermaid
 stateDiagram-v2
-    [*] --> systemd: client connects
+    [*] --> systemd: first client connects
     systemd --> podman: socket inherited via fork/exec
 ```
 
@@ -55,6 +55,9 @@ $ export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock
 $ docker-compose up
 ```
 
+When __docker-compose__ or any other client connects to the UNIX socket `$XDG_RUNTIME_DIR/podman/podman.sock`,
+the service _podman.service_ is started. See its definition in the file _/usr/lib/systemd/user/podman.service_.
+
 ## Socket activation of containers
 
 Since version 3.4.0 Podman supports socket activation of containers, i.e.,  passing
@@ -65,7 +68,7 @@ as can be seen in the following diagram:
 
 ``` mermaid
 stateDiagram-v2
-    [*] --> systemd: client connects
+    [*] --> systemd: first client connects
     systemd --> podman: socket inherited via fork/exec
     state "OCI runtime" as s2
     podman --> conmon: socket inherited via double fork/exec
@@ -207,6 +210,18 @@ container then runs with less privileges.
 When using rootless Podman, network traffic is normally passed through slirp4netns. This comes with
 a performance penalty. Fortunately, communication over the socket-activated socket does not pass through
 slirp4netns so it has the same performance characteristics as the normal network on the host.
-Note, there is a delay when the first connection is made because the container needs to
+
+### Starting a socket-activated service
+
+There is a delay when the first connection is made because the container needs to
 start up. To minimize this delay, consider passing __--pull=never__ to `podman run` and instead
-pull the container image beforehand.
+pull the container image beforehand. Instead of waiting for the start of the service to be triggered by the
+first client connecting to it, the service can also be explicitly started (`systemctl --user start echo.service`).
+
+### Stopping a socket-activated service
+
+Some services run a command (configured by the systemd directive __ExecStart__) that exits after some time of inactivity.
+Depending on the restart configuration for the service
+(systemd directive [__Restart__](https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart=)),
+it may then be stopped. An example of this is _podman.service_ that stops after some time of inactivity.
+The service will be started again when the next client connects to the socket.