Hello! The kind of “service” that Guix manages is those described here:
https://www.gnu.org/software/guix/manual/en/html_node/Service-Composition.html The first paragraph tries to explain it: Here we define a “service” as, broadly, something that extends the functionality of the operating system. Often a service is a process—a “daemon”—started when the system boots: a secure shell server, a Web server, the Guix build daemon, etc. Sometimes a service is a daemon whose execution can be triggered by another daemon—e.g., an FTP server started by ‘inetd’ or a D-Bus service activated by ‘dbus-daemon’. Occasionally, a service does not map to a daemon. For instance, the “account” service collects user accounts and makes sure they exist when the system runs; the “udev” service collects device management rules and makes them available to the eudev daemon; the ‘/etc’ service populates the ‘/etc’ directory of the system. For services that “map to a daemon”, you’d extend ‘shepherd-root-service-type’ by providing a Shepherd service. A Shepherd service is a service managed by PID 1. You can list them on a running system by running ‘herd status’ as root. IOW, Shepherd services are a special case of service. Just like D-Bus services are another special case, etc. About logging: Shepherd does very little in that area. It limits itself to providing a #:log-file parameter to capture the processes’s stdout/stderr to a file. Other than that we usually configure daemons to write to syslog, which provides more flexibility regarding storage and filtering of log entries. A “non-Shepherd service” as you call them doesn’t necessarily map to a process, so there’s potentially nothing to log in the first place. Does that answer your questions? Thanks, Ludo’.
