docs: #6257 add conceptual note in the explanation section#6264
Open
shaloo wants to merge 8 commits into
Open
Conversation
shaloo
changed the title
shaloo
changed the title
shaloo
commented
May 28, 2026
Signed-off-by: shalz <shalz@hotmail.com>
Author
|
The connection errors during lint are due to network issues - not due to content. Not sure why CVE errors are showing up here and how/whether we need to wait and merge those fixes from elsewhere before this PR can be reviewed/processed. |
bepri
reviewed
May 29, 2026
Member
bepri
left a comment
bepri
left a comment
There was a problem hiding this comment.
Looks good so far, thanks! There's a lot of comments, but they're largely touching up on some style choices that were common "back then" but have been revised since.
| .. _explanation-services-daemons: | ||
|
|
||
| Services and daemons | ||
| ====================== |
Member
There was a problem hiding this comment.
Suggested change
| ====================== | |
| ==================== |
| Services and daemons | ||
| ====================== | ||
|
|
||
| When :ref:`creating snapcraft.yaml <explanation-snapcraft-yaml>` to build a new snap, a snap’s executable component can be either exposed as a command or run as a background service or daemon. |
Member
There was a problem hiding this comment.
We generally prefer to use the term "project file" over "snapcraft.yaml" where possible (this applies to many other places in this document too)
| Services and daemons | ||
| ====================== | ||
|
|
||
| When :ref:`creating snapcraft.yaml <explanation-snapcraft-yaml>` to build a new snap, a snap’s executable component can be either exposed as a command or run as a background service or daemon. |
Member
There was a problem hiding this comment.
Suggested change
| When :ref:`creating snapcraft.yaml <explanation-snapcraft-yaml>` to build a new snap, a snap’s executable component can be either exposed as a command or run as a background service or daemon. | |
| When :ref:`creating snapcraft.yaml <explanation-snapcraft-yaml>` to build a new snap, a snap's executable component can be either exposed as a command or run as a background service or daemon. |
There's a number of these ⭐ Fancy Apostrophes ⭐ in this, could you replace them?
Comment on lines
+25
to
+30
| :: | ||
|
|
||
| apps: | ||
| part-os-release: | ||
| command: bin/os-release.sh | ||
| daemon: simple |
Member
There was a problem hiding this comment.
Suggested change
| :: | |
| apps: | |
| part-os-release: | |
| command: bin/os-release.sh | |
| daemon: simple | |
| .. code-block:: yaml | |
| apps: | |
| part-os-release: | |
| command: bin/os-release.sh | |
| daemon: simple |
| The value for ``daemon:`` can be one of the following: | ||
|
|
||
| - ``simple``: Run for as long as the service is active - this is typically the default option. | ||
| - ``oneshot``: Run once and exit after completion, notifying systemd. After completion, the daemon is still considered active and *running*. |
Member
There was a problem hiding this comment.
Suggested change
| - ``oneshot``: Run once and exit after completion, notifying systemd. After completion, the daemon is still considered active and *running*. | |
| - ``oneshot``: Run once and exit after completion, notifying systemd. After completion, the daemon is still considered active and running. |
| If the ``dbus`` type is used, either the ``bus-name`` keyword or ``activates-on`` keyword must be used to define a bus name for the daemon. If both keywords are defined, the bus name takes precedence. If only the ``activates-on`` keyword is defined, the last name in its list of slots is used as the bus name. | ||
|
|
||
| Activation | ||
| ~~~~~~~~~~~ |
Member
There was a problem hiding this comment.
Suggested change
| ~~~~~~~~~~~ | |
| ~~~~~~~~~~ |
| Activation | ||
| ~~~~~~~~~~~ | ||
|
|
||
| The ``activates-on`` keyword is used to define a list of names that will be exposed via D-Bus. These names are automatically added to the slots for the snap. |
Member
There was a problem hiding this comment.
Suggested change
| The ``activates-on`` keyword is used to define a list of names that will be exposed via D-Bus. These names are automatically added to the slots for the snap. | |
| The ``activates-on`` key is used to define a list of names that will be exposed via D-Bus. These names are automatically added to the slots for the snap. |
| This provides a way for a daemon to be started on a D-Bus method call. When a method on any of the names is invoked, the daemon’s ``command`` is run to start the daemon. | ||
|
|
||
| General use | ||
| ~~~~~~~~~~~~ |
Member
There was a problem hiding this comment.
Suggested change
| ~~~~~~~~~~~~ | |
| ~~~~~~~~~~~ |
| General use | ||
| ~~~~~~~~~~~~ | ||
|
|
||
| A daemon that needs to provide services to applications can be configured to use a bus name by setting its ``bus-name`` keyword. This enables the system bus to be used for communication, as with regular system daemons. |
Member
There was a problem hiding this comment.
Suggested change
| A daemon that needs to provide services to applications can be configured to use a bus name by setting its ``bus-name`` keyword. This enables the system bus to be used for communication, as with regular system daemons. | |
| A daemon that needs to provide services to applications can be configured to use a bus name by setting its ``bus-name`` key. This enables the system bus to be used for communication, as with regular system daemons. |
|
|
||
| A daemon that needs to provide services to applications can be configured to use a bus name by setting its ``bus-name`` keyword. This enables the system bus to be used for communication, as with regular system daemons. | ||
|
|
||
| The ``daemon`` keyword does not need to specify the ``dbus`` type for this use case, unless it is convenient to notify *systemd* about start-up by claiming a D-Bus name. |
Member
There was a problem hiding this comment.
Suggested change
| The ``daemon`` keyword does not need to specify the ``dbus`` type for this use case, unless it is convenient to notify *systemd* about start-up by claiming a D-Bus name. | |
| The ``daemon`` key does not need to specify the ``dbus`` type for this use case, unless it is convenient to notify systemd about start-up by claiming a D-Bus name. |
bepri
reviewed
May 29, 2026
Member
bepri
left a comment
bepri
left a comment
There was a problem hiding this comment.
Looks good so far, thanks! There's a lot of comments, but they're largely touching up on some style choices that were common "back then" but have been revised since.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Based on user feedback regarding missing information (#6257) I have pulled changes verbatim from the Forum's post
make lint && make test.