vera is an alternative init daemon supervisor (PID 1) that uses containers.
Containers allow reliable, foolproof shutdown and termination of started
services. vera was developed on Slackware 15.0. It is capable of booting and
shutting down a stock installation of Slackware 15.

https://github.com/svarshavchik/vera/releases/tag/0.93

Changes: as a proof of concept, this release adds an extra feature on top of
the stock Slackware installation: an optional system/networkmanager-wait-
online container for Slackware systems that use NetworkManager. This
container runs /usr/bin/nm-online, from the NetworkManager package before
starting rc.inet2 services. Other distributions have something similar, this
implements it for Slackware.

Hi,

On Fri, 12 Apr 2024 07:47:43 -0400, Sam wrote:

> vera is an alternative init daemon supervisor (PID 1) that uses
> containers. Containers allow reliable, foolproof shutdown and
> termination of started services. vera was developed on Slackware 15.0.
> It is capable of booting and shutting down a stock installation of
> Slackware 15.
>
> https://github.com/svarshavchik/vera/releases/tag/0.93
>
> Changes: as a proof of concept, this release adds an extra feature on
> top of the stock Slackware installation: an optional
> system/networkmanager-wait- online container for Slackware systems that
> use NetworkManager. This container runs /usr/bin/nm-online, from the
> NetworkManager package before starting rc.inet2 services. Other
> distributions have something similar, this implements it for Slackware.

I didn't know about vera or other similar package for other Linux distros.
What problems does it try to solve.
I don't use to get problems shutting down started services.

Does it improve security by isolating the services?

Luis Mendes writes:

> I didn't know about vera or other similar package for other Linux distros.
> What problems does it try to solve.
> I don't use to get problems shutting down started services.

There are a few minor networkmanager-related issues that affect a small
minority, that vera fixes.

> Does it improve security by isolating the services?

No, there is no process isolation.

vera offers more features that are available from sysvinit. Of course, if
all one's doing is running a base Slackware system, with no customization,
there won't be much here.

Sam <sam@email-scan.com> wrote:
> vera is an alternative init daemon supervisor (PID 1) that uses containers.

Where do these containers come from? I assume they are built in
to vera? If so, what properties or restrictions do they have?
Might they be useful for containerizing other processes?

I did have a look at the github, but am none the wiser.

#Paul

#Paul writes:

> Sam <sam@email-scan.com> wrote:
> > vera is an alternative init daemon supervisor (PID 1) that uses containers.
>
> Where do these containers come from? I assume they are built in
> to vera?

vera creates them. They are kernel containers. vera uses the current cgroup2
container API. systemd is using the original "version 1" kernal containers.

See the cgroups(7) man page for all the gory details.

> If so, what properties or restrictions do they have?

The containers are unrestricted. Their main benefit is that they make it
trivial to shut down what's been started. Any process forked off from an
existing process in a container runs in the same container. So, when you
want to stop a started service, it's a no-brainer. It's possible to do other
things with containers, like limit the maximum number of processes per
container, mitigating any potential fork-bombs, or set the maximum amount of
RAM processes in the container could use.

Slackware already uses containers, in the form of the elogind service (since
it's based off systemd code elogind uses version 1 kernel containers). This
is for the same reason if you log out and has something running in the
background it's going to get killed. elogind creates a container for your
login session. When you log out everything in the container get killed.

> Might they be useful for containerizing other processes?

You can define your own. Here's one for ntpd (that gets automatically
created when vera gets installed):

name: rc.ntpd
description: /etc/rc.d/rc.ntpd
starting:
type: forking
command: /etc/rc.d/rc.ntpd start
stopping:
type: manual
command: /etc/rc.d/rc.ntpd stop
before:
- rc.autofs
x-chmod-script: /etc/rc.d/rc.ntpd
Version: 1

Create something similar, that looks like that, that starts or stops
whatever you want. Or, leave off the stop command entirely, and all started
processes will be terminated upon demand.

(x-chmod-script is specific to Slackware's default initscripts, and keeps
this in sync with what initscripts thinks is enabled, or not, and "before"
is for ordering stuff at shutdown, ignore that, or specify your own explicit
order if you create multiple containers)

On Tue, 23 Apr 2024 17:58:12 -0400, Sam wrote:
> Slackware already uses containers, in the form of the elogind service
> (since it's based off systemd code elogind uses version 1 kernel
> containers). This is for the same reason if you log out and has
> something running in the background it's going to get killed. elogind
> creates a container for your login session. When you log out everything
> in the container get killed.

I had to make a quick test, this does not seem to apply to ssh sessions
on a rather stock Slackware 15.0:

-8<--------------------------------------
henca@munin:~> sleep 2000 &
[1] 31437
henca@munin:~> exit
logout
Connection to munin closed.
nazgul:~> ssh munin
Last login: Thu Apr 18 18:29:19 2024 from 192.168.43.9
Linux 5.15.19.

There is more simplicity in the man who eats caviar on impulse than in the
man who eats Grap-Nuts on principle.
-- G.K. Chesterton

henca@munin:~> ps -auxwww | grep sleep
henca 31437 0.0 0.0 2976 1588 ? S 07:36 0:00 sleep
2000
henca 31481 0.0 0.0 3984 2148 pts/1 S+ 07:36 0:00 grep
sleep
henca@munin:~>
-8<--------------------------------------

So in the example above my sleep background process survived a logout.

regards Henrik

Henrik Carlqvist writes:

> On Tue, 23 Apr 2024 17:58:12 -0400, Sam wrote:
> > Slackware already uses containers, in the form of the elogind service
> > (since it's based off systemd code elogind uses version 1 kernel
> > containers). This is for the same reason if you log out and has
> > something running in the background it's going to get killed. elogind
> > creates a container for your login session. When you log out everything
> > in the container get killed.
>
> I had to make a quick test, this does not seem to apply to ssh sessions
> on a rather stock Slackware 15.0:
>
> -8<--------------------------------------
> henca@munin:~> sleep 2000 &
> [1] 31437
> henca@munin:~> exit
> logout
> Connection to munin closed.
> nazgul:~> ssh munin
> Last login: Thu Apr 18 18:29:19 2024 from 192.168.43.9
> Linux 5.15.19.
>
> There is more simplicity in the man who eats caviar on impulse than in the
> man who eats Grap-Nuts on principle.
> -- G.K. Chesterton
>
> henca@munin:~> ps -auxwww | grep sleep
> henca 31437 0.0 0.0 2976 1588 ? S 07:36 0:00 sleep
> 2000
> henca 31481 0.0 0.0 3984 2148 pts/1 S+ 07:36 0:00 grep
> sleep
> henca@munin:~>
> -8<--------------------------------------
>
> So in the example above my sleep background process survived a logout.

This looks like a bug, somewhere. I repeated this experiment, and grepped
/sys/fs/cgroup/elogind/*/cgroup.procs, and that cgroup still exists, with
sleep's pid in it.

That's the whole purpose of elogind, as I understand it. The very first
bullet point of the elogind man page says:

• Keeping track of users and sessions, their processes and their idle
state

I don't know "keeping track" means, then. Additionally, each ssh session
creates a new cgroup in /sys/fs/cgroup/elogind, and the old ones don't get
cleaned up. Even if I kill the sleeping pid, its cgroup is left behind and
remains empty.

The only thing I can think of is perhaps the intent here is not to clean up
at logout but provide the means to terminate the session on demand.

However, "loginctl list-sessions" no longer shows the sshd session after
logging out, despite its container being there with the sleeping process in
it.

I repeated the same experiment on Fedora, with systemd.

- After logging off, "loginctl list-session" continued to show the container
with the sleeping pid in it, but it's status shown as "closing".

- After killing the pid, the session was gone, and the container in
/sys/fs/cgroup was automatically removed (the container hierarchy is more
complicated, with full systemd, but the general idea is the same).

That's as much investigation I could complete before having my morning
coffee. At least on Fedora, the equivalent modus operandi seems to be: don't
kill the lingering processes automatically, but provide the means to
terminate them on demand. I don't think elogind is managing to do this
correctly, quite…