dinit and Vera?

[rizitis]

Hello thanks for your work, this is not an issue its just a though. I think vera will work together with dinit very very well with some modifications... So every project will have its own space in system and specific work to do... It might look as systemd with other name at the end, but it not exaclty.

1. dinit and Vera: These systems do not enforce complete control or execution of every service through a unified system, as systemd does. Instead, they allow users to choose how to start their services, using either traditional scripts or modern container approaches. systemd: Integrates many services and functionalities that may be unnecessary for some users. This approach can lead to greater dependency on systemd and limit flexibility in how users manage their services.

2. Better Flexibility dinit: Provides a flexible service management mechanism that allows users to define dependencies and start services without requiring adjustments to complex settings. Vera: Uses containers to isolate services, allowing users to run multiple services in parallel without needing complex configurations. This capability offers greater flexibility in developing and managing applications.

3. Third-Party Development dinit and Vera: Are open-source, and users have the freedom to add and modify their functionalities without being constrained by the framework imposed by systemd. systemd: Although also open-source, its development is more centrally controlled, with fewer options for third-party developers to add their functionality without needing to integrate systemd into their entire project.

4. Design and Philosophy dinit and Vera: Follow UNIX principles that focus on simplicity, transparency, and ease of use. Their design encourages the use of tools that perform a specific task well, rather than unifying multiple functions into a single tool. systemd: Tries to offer a single solution for service management, which can lead to complexity and delays in understanding and using it.

   5. Better Support for Customization dinit and Vera: Provide more options for users on how to organize and manage their services. Users can choose the settings and approaches that best fit their needs. systemd: Integrates many predefined settings and can limit users' flexibility to customize their environment according to their preferences.

Conclusion:

Overall, dinit and Vera together will offer an alternative approach to service management and system operation that is less intrusive and more flexible than systemd. These differences make dinit and Vera attractive choices for users and administrators who prefer a simpler and lighter approach to service and resource management.

Just some thoughts... thank you!

[svarshavchik]

I'll agree in part and disagree in part with the first point. Everything started by vera gets started in its own container. What might be misleading is that it seems that everything still gets started from a single monolithic /etc/rc.d/rc.M (and /etc/rc.d/rc.inet1) script. This is a sleight of hand. What happens is that rc.{M,inet1} get modified on the fly before they're executed and every occurence of "/etc/rc.d/rc.something start" gets replaced by "vlad start ". A few other things get a similar treatment. This is only an interim measure. At some point in the bright future initscripts get completely replaced by individual container specification files, and all that scaffolding can go away.

But what is true is that, with some additional work, vera can be started independently, instead of pid 1, and it'll manage its own containers, and nothing else, have a sort of a container-based subsystem while the system itself is still running init. I thought about doing some work to make that option happen but ultimately decided that this will add too much complexity. I'm happy running vera as pid 1, now, and don't really see much value-added in this kind of a hybrid approach.

I also debated with myself if I wanted to also replace elogind. About 80% of what elogind does is already implemented in vera, and only a few more bits need to be added before elogind /etc/pam.d/ can be replaced by whatever this will be called. For now I decided to hold off on that.

[rizitis]

Thanks for answers, you made clear things I dint understand! So if i understand right I have an /etc/rc.d/rc.my_service which now start from rc.local, if my rc.local edited like this

vlad start rc.my_service

is enough ?

[svarshavchik]

No, vera has special handling for rc.M and rc.inet1 that works basically like that.

vlad start

starts a container with the given name. vera has additional scaffolding that parses rc.M and rc.inet1, and cross-checks it with the contents of /etc/rc.d, and then creates a container specification file for it.

Then rc.M is dynamically fudged, on the fly, replacing direct rc.d script invocations with vlad commands.

My rc.M is unchanged. This part of it:

# Start Apache web server:
if [ -x /etc/rc.d/rc.httpd ]; then
  /etc/rc.d/rc.httpd start
fi

Gets fudged, on the fly, to run "vlad start" if rc.httpd is executable. The following gets automatically created, as /lib/vera/system/rc.M/rc.httpd:

description: /etc/rc.d/rc.httpd
starting:
  type: forking
  command: /etc/rc.d/rc.httpd start
stopping:
  type: manual
  command: /etc/rc.d/rc.httpd stop
  before:
  - rc.postfix
restart: /etc/rc.d/rc.httpd restart
x-chmod-script: /etc/rc.d/rc.httpd
Version: 1

So, if rc.M decides to start apache, it'll start this container, and one can always run "vlad start" or "vlad stop" from the shell.

This fudging is done only for rc.M and rc.inet1. rc.local is handled differently, it basically gets run, as is, in its own container. Everything that's started from rc.local, as is, runs in the same container.

This was needed because rc.local is, basically, a black box that's invoked from rc.M, and it has no structure to it. So, when vera is installed, rc.local gets renamed, a stub is left in its place that does nothing, and a separate container specification is installed that runs the renamed rc.local, and rc.local_shutdown.

One can, however, install S##something (and K##something) in /etc/rc[345].d, and each one of these will get its own container.

[rizitis]

So

1. For rc.M and rc.inet1: Vera modifies these scripts dynamically to replace direct service invocations with vlad start commands.
2. For rc.local: It is handled as a single unit and executed within its own container. User don’t need to modify rc.local to use vlad for services or commands started from it.
3. For scripts in /etc/rc[345].d/: Each script will get its own container when run, and vlad commands will be automatically handled by Vera.

[svarshavchik]

Yup, that's pretty much it.

You are free to create your own unit specification files yourself, and put "vlad start" into your rc.local script. It'll run, and it'll start a separate container for whatever you want to run in it. However you'll also need to put "vlad stop" into rc.local_shutdown, in order to stop it.

But for something completely independent, there's no need to modify anything. Just install a unit specification file that correctly defines its dependencies. So, for example, install /lib/vera/gizmo with the following contents:

name: gizmo
description: Start my gizmo
required-by:
- /system/custom
- /system/graphical
- /system/multi-user
- /system/networking
starting:
  type: forking
  command: /usr/bin/gizmo start
stopping:
  type: manual
  command: /usr/bin/gizmo stop

Version: 1

and the gizmo will get started in these runlevels, without any changes to initscripts.

Now, of course, the start will happen simultaneously with everything else that gets started in these runlevels (while everything from rc.M is running).

In most cases you'll want your stuff started after everything else that happens at startup actually happens. That will require specifying before and after dependencies.

And if you want only ondemand stuff: get rid of required-by, and all dependencies, and just run "vlad start gizmo" and "vlad stop gizmo" yourself, on demand.