Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Services format #2

Open
DanySpin97 opened this issue Dec 15, 2019 · 8 comments
Open

Services format #2

DanySpin97 opened this issue Dec 15, 2019 · 8 comments

Comments

@DanySpin97
Copy link
Owner

@DanySpin97 DanySpin97 commented Dec 15, 2019

s6-rc handle oneshot, longrun and bundle.

Format

Oneshot

[main]
name="myservice"
polish_name="My service, handler of x,y,z."
description="Cool description"
type="oneshot"

[start]
# Interpreter for the script. Can be any of "sh", "execline", "bash", "zsh"
type=execline
#type=custom
#shebang="#!/path/to/script/intepreter"
user="mysystemuser" # Cannot be changed for user services
group="mysystemgroup" # Cannot be changed for user services
execute="Actual script"

[stop]
# same as [start]

[options]
# Can be enabled by root (system service). Default: true
root_enabled=true
# Can be enabled by user. Default: false
user_enabled=false
dependencies=(fooA fooB)
optional_dependencies=(fooC fooD)

[config]
# env variables are listed there
KEY="VALUE"

Longrun

[main]
# same as oneshot [main]
...
type="longrun"

[run]
# same as [start]

[logger]
# same as [start]
...
# additional logger options
...

[options]
...

[config]
...

Bundle

[main]
...
type="bundle"

[bundle]
contents="service3 service4"

Downside of s6-rc

  • All the depencies listed for a service should be available on the system. Example I want to distribute a is_connected service that depends on all the network daemons (connman, NetworkManager, etc) and then simply wait for the one that are available at runtime. This is not possible with s6-rc because it is designed to be predictable. A workaround would be defining a list of conditional dependencies and, at database compile time, all the services contained in this list that are enabled on the system would be listed as normal dependencies. Optionally, some flags could be added if at least one is needed.

  • The bundle does not take dependencies. Workaround: The bundle dependencies get added to its content.

  • Bundle are not valid deps. Workaround: Add all the bundle contents in its place.

@Cogitri

This comment has been minimized.

Copy link
Collaborator

@Cogitri Cogitri commented Dec 16, 2019

One minor nitpick: I think runas is a bad name for this, I'd much prefer user and group.

Example I want to distribute a is_connected service

Maybe we could have 'targets' like systemd?

Other than that this looks good to me.

@DanySpin97

This comment has been minimized.

Copy link
Owner Author

@DanySpin97 DanySpin97 commented Dec 16, 2019

One minor nitpick: I think runas is a bad name for this, I'd much prefer user and group.

Yup, they are definitely better.

Maybe we could have 'targets' like systemd?

Targets are more like runlevels, and I don't want to add them if it is possible. Conditional deps imho are more flexible and would be used a lot in web services, where there are multiple configurations possible. I.e. fail2ban uses iptables but can also be configured to use nftables; by having both as conditional deps, it could work out of the box without any configuration in tt. This would also leave everything in one database so they would be started as soon as possible.

Target-like options would be needed imho to divide the boot services from the other ones. I don't think a "graphic target" is needed at all, it could be expressed using dependencies.

There is also the matter with the concept of trees, which 66 based itself, but I will open a new issue to discuss it.

@Cogitri

This comment has been minimized.

Copy link
Collaborator

@Cogitri Cogitri commented Dec 16, 2019

Target-like options would be needed imho to divide the boot services from the other ones. I don't think a "graphic target" is needed at all, it could be expressed using dependencies.

I don't think we need a graphic target either, but I'd really like something that groups together multiple services providing the same functionality (maybe we could call those providers :P)

@DanySpin97

This comment has been minimized.

Copy link
Owner Author

@DanySpin97 DanySpin97 commented Dec 16, 2019

something that groups together multiple services providing the same functionality

Yea, that would be awesome too. Let's call them providers then. Some examples other than network? I was thinking about relational db too, but I can't think of other examples.

@Cogitri

This comment has been minimized.

Copy link
Collaborator

@Cogitri Cogitri commented Dec 16, 2019

Hm, maybe "Display Manager" or "User Environment"? Users might desire functionality like systemd-user offers to manage GUI applications via the service manager too.

@Cogitri

This comment has been minimized.

Copy link
Collaborator

@Cogitri Cogitri commented Dec 16, 2019

I guess something like IPC being provided by both dbus and dbus-broker would be a candidate for this too? (although I think dbus-broker is systemd specific)

@DanySpin97

This comment has been minimized.

Copy link
Owner Author

@DanySpin97 DanySpin97 commented Dec 16, 2019

Hm, maybe "Display Manager" or "User Environment"?

No need for them, because the user environment has its own scandir and could be made to start at login.

I guess something like IPC being provided by both dbus and dbus-broker would be a candidate for this too?

Like starting services by dbus when needed? It is indeed a neat feature.

What instead I would be happy do have, is user services that depend on system ones, which needs to be done all in tt.

@Cogitri

This comment has been minimized.

Copy link
Collaborator

@Cogitri Cogitri commented Dec 17, 2019

Like starting services by dbus when needed? It is indeed a neat feature.

Ah yes, that's a neat feature, but I actually just wanted to come up with examples for providers :)

What instead I would be happy do have, is user services that depend on system ones, which needs to be done all in tt.

Hm, in what scenario do you need such fine grained dependencies? In my mind it'd always be OK to first finish starting all of the system services and then start the user ones (or do you just mean that a user can say "I want to start user service X which needs system service Y"?)

@DanySpin97 DanySpin97 changed the title Services Services format Jan 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.