[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Gentoo guys starting a fork of udev



I have an additional perspective that (I think sharing) would help
this discussion.

Although this thread was started to discuss udev - and not argue about
sysv / systemd....

 -> I think I should state it here.

 -> Perhaps, after I have given my rationale, you will recognize why I
think it is important to state here. If not, then I appoligize for the
intrusion, but I think you might be interested to give this a read and
consider what it says.

 -> I am not trying to be a jerk here (believe me), but I think some
ideas have gotten merged together that were originally designed to be
separate, and I am going to try to highlight why (I think) it was
designed that way (and should stay that way if no better idea is
presented).


I have some questions I am legitimately presenting. They might seem a
bit harsh, but I am trying to snap people out of what I think is a bit
of a mental fog that has many people exhausted, upset, and frustrated.

I am not trying question aggressively, so please don't read them as if
you're being attacked.

I've got some questions that I think _if no answer can be given_, we
have a problem with the current direction this is going and a full
stop and careful examination are in order.


I think it is categorically important to *identify* and *convey to the
community*...

 -> What role is systemd designed to facilitate?


Please don't answer with a reference to read some kind of
documentation. If an answer can be given, it should be manageable
enough for someone to simplify it and type it up in their own words.


On 19 November 2012 04:23, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
[...]
> For example, sysvinit cannot prevent a process from forking away.

A few things:

 -> Do we know why we want to prevent a process from forking? It helps
to have a blueprint showing you what needs to be built (and tested)
and stop us from building things that don't operate within the
blueprint. It also shows how the mechanisms operate and operate with
one another.

 -> If it's never supposed to fork, why not just remove forking from
the architecture? It seems reasonable to keep it because it
categorically is equivalent to calling a function in a program, and
functions are very useful in programming.

 -> Let's hypothetically decide to prevent a fork on some conditional
basis (as opposed to no forks at all).....is it systemd's
responsibility, or would that fall to the responsibility of the linux
kernel?



> Once sysvinit has started a daemon, the daemon can pretty much do whatever
> it wants provided it has enough permissions. On systemd, there are
> means to prevent that.


Yes, provided it has _enough_ permissions, a program can do whatever it wants.

This is where microsoft failed to really comprehend the idea of
_minimal_ permissions from unix.

Reasons that should be checked against the logic of a better reason
provided by the systemd group...

 -> If simply checking that the daemon's permissions were set
correctly before execution would solve this problem, then it would
make sense that a system redesign need not be in order.

 -> Usually when things are installed, their permissions are set by
the install routine, and the administrator is usually the *only* one
who can change them, so why would systemd be involved in this?

 -> Enforcing permissions is the responsibility of the linux kernel.
Not systemd. The kernel is launched first because it basically is the
system authority. It controls the system. It polices the running
processes and refuses to allow programs to do things they have not
been granted permission to do. Minimal. It is a whitelist security
model and they work very well in a minimal permission environment. Why
should this model be changed, and why should systemd enter into the
authority architecture of the system?

 -> Establishing and maintaining the permissions is the responsibility
of the administrator (usually with the help of a package manager). Not
systemd. Why should systemd take control of this? Or to rephrase : if
systemd assumed control of this, it would make systemd the
administrator of the system : that role has already been defined and
*isolated* as the authority of the root user : *compromising the
isolation* is what allowed computer viruses to reach epidemic
proportions (on windows machines : D   )

 -> POSIX capabilities is already in place to prevent/hamper runaway
things from wrecking the system. Is this model fundamentally flawed in
some fashion? Should systemd have domain over this? Why should this no
longer fall under the domain of the system authority, the linux
kernel?



> Another thing is making sure that a daemon is actually
> running. systemd always knows the state of a daemon and can restart
> it, if necessary.


Well what if some modifications to the init scripts where made
something along the lines of....

 -> (launch process & store pid of launch in run/pid folder || check
if pid file is there in failure)

 -> in process, upon successful stop, remove pid file

 -> launch process failure alt execution : inform via some message
facility that pid file was not removed, process crashed. Do it this
way and a daemon crash will be signalled rather immediately.

And more importantly..... why should systemd be involved in this? What
does systemd do that the daemon's launch routine cannot accommodate?



> The result is that none of the autofs mounts work until autofs has been manually
> restarted. On systemd, this won't happen, because systemd is aware of
> the fact that NIS and rpcbind need to be up and running before autofs
> can do anything sensible.


Why not just modify _autofs_ to check upon startup....

 -> the locations in the autofs config file are actually mounted (mtab)

 -> the link is up for the default route autofs uses (somewhere eth0
link up...etc..)

 -> if these conditions are unmet, can autofs just background and wait
(for a certain time, or indefinite, or none) and in parallel to
waiting, monitor the file descriptors (/proc/pid_of_fsck/fd/whatever)
for the /dev/whatever device to see when it's done being fscked.

This seems like an logic improvement that should be made to autofs,
and not have systemd make that logic improvement for autofs. Or
perhaps come up with a generic /etc/automount.d (or something, maybe
even in proc) and then a lot of common daemons can have a common place
to check that the system is ready to let them fully start up, and to
simply background themselves and wait whlie the system is starting &
fsck is scanning stuff.

Why should systemd be involved in this? Not everybody has a need for
autofs, likewise, not everybody should need systemd to handle a
problem with autofs for autofs/them.



> And thirdly, if you have very large file systems (we have a 30TB
> hardware raid here, for example), filesystem checks can take
> forever. If you reboot such a server and it needs to do an fs check,
> it will be unavailable until the check has finished. With systemd, you
> can just declare the filesystem as an automount [1] and the system
> still boots while the filesystem checks are performed.


First.... the data in the volume won't be available until the fsck
completes, so the server won't be able to give the data any faster
than it takes to fsck the volume. Minimum time limit, unless you have
a new filesystem check design to get around this, that is a rather
unchangeable wait time until you can *serve* the data.... You might
investigate why fsck takes the time it does and how could fsck be made
faster.

Would this not work just as well....

 -> when installing the system, it makes sense to have separate mount
points for massively large file systems, that way the system can be
booted, the fsck can be backgrounded, and then autofs can check for
when fsck releases the file descriptor to the device, and then it can
mount it. If you do that, it should in theory, be the fastest it can
be made available (to serve/use).


If you have a crap ton of programs all waiting for a volume to be
available, you should use *run levels*. You can have more than just 6
runlevels btw.

boot -> network, ntpd, start volume scans runlevel......when scans
finished -> daemons that need scanned volume runlevel....  -> if scans
fail, don't launch next runlevel. Make last runlevel require
successful fsck (and network if needed) and that prevents *a lot* of
the hitting of the fans.


It seems that systemd is trying to take over the responsibility of...

 -> the linux kernel's authority over other processes (permissions
keep the peace, not systemd)

 -> the system inter process communication facility to inform, not
systemd (I guess.... itself), that something has crashed and something
should be done about it. Another daemon could be written that simply
checks when the *file descriptors* of any of the pid files closes, and
if the file wasn't deleted, we have a problem, inform some system
facility... We don't need to replace the daemon launch facility with a
job that could be delegated to another daemon... and launch it with..
( exec watchdog || exec watchdog "you killed yourself dummy" )

 -> the authority granted to the system administrator, who's job is to
administer the system and no one else's

 -> picking up the slack for poorly written programs that crash (as in
auto relaunch a daemon). Don't do this. Demand (or help) the software
fix its internal problems or back another (software) implementation of
what that software's job was. If you drop crappy software off by the
side of the road, then people start writing better software. If no one
objects to a daemon crash because a crash was (silently) trampolined
under the hood...well...in short, you start setting up fans for what
will eventually hit them (and you too).

 -> enforcing a new model on the entire linux community for a problem
that tips and tricks for admins could advert.


It seems many lines have been blurred and I am trying to bring them
back in to focus. They were drawn up as lines for reasons. They should
only be changed with better reasons. I am not trying to discourage
change. I am trying to give you something to help you determine if
another reason is a _better_ reason.


So, I think for udev's future, for linux's future, we check our
bearings here and see if we are going in the direction we initially
set out in. Have we gotten sidetracked from the path we meant to take?


So, to repeat the first question so we end on the highest point....


I think it is categorically important to *identify* and *convey to the
community*...

 -> What role is systemd designed to facilitate?



-Kev


Reply to: