On 18/04/2017 at 15:11, karl@??? wrote:
> Alessandro Selli:
> ...
>> And
>> what I don't like of Karl Aspo's idea is that it takes any instrument of
>> policy checking and enforcing out of the monitor, which ends up not
>> being able to monitor anything, it becomes just a shell: fire and forget.
> I honestly do not understand what I have written which gives you that idé.

Your many lines that the monitor is not to do any monitoring. Like:
"Why do any monitor program need to know if the program has detached or
not, the only thing it needs to know is the pid and the state,".

>> I was also been ironic on Aspo, as many times he can only counter
>> another person's ideas asking "What if <something> cannot be trusted?",
>> as if this constitutes a valid argument against being able to set
>> policies for the monitor to enforce on the daemons it runs.
> If I can get a value from the kernel instead of from the process,
> I'd take the kernel value.

What value? Of course there are values that are set and managed by
the kernel, not by the process, and are thus most dependable when
extracted from the kernel itself. However other values are specific to
the daemon and the kernel doesn't care/know anything of, like what
virtual domains the webserver is handling, of how many domains the DNS
server is master. Anyway, this has very little (if anything) to do with
the monitor's need to be able to... monitor the processes it launches,
set them to the wanted user:group and the daemons knowing whether they
are to detach from the controlling terminal or not.

> Why do a process have to query the kernel to get a value and then
> sending it to a monitor over a communication link; why don't the
> monitor query the kernel itself, saving one step.

Where did Enrico Weigelt write the monitor should get it's child PID
from the process itself? This subthread started from these lines:

>> * srvmgt_droppriv(...)
>> --> drop root privileges (if we are still root)
>> --> several versions, eg. with fetching the target uid/gid from env
> Given the pid, it isn't that hard for a monitor to find the uid/gid of
> the process, why has this have to go through the monitor ?


>> In this
>> case, asking "why should a program/daemon care if it has a monitor or
>> not ?" is moot, because that the daemon is aware or not that it was
>> launched by a monitor and if so by what monitor, does not change
>> anything about the monitor's functions and duties. The daemon doesn't
>> care if it's run by a monitor? The monitor is still there, and it does
>> care about the program.
> It would help my understanding if you simply answered my question.

An answer to a moot question is Mu!
(https://en.wikipedia.org/wiki/Mu_%28negative%29)
The only point of any technical interest was already answered:

«All daemons detach from the control terminal. The monitor and the
daemon must coordinate each other about who's doing the detach to avoid
launch time failures.»

And again, so long as it's configured the right way, that the daemon
is aware that it is run under a monitor or not is irrelevant: it is the
monitor that need to be aware of it's children processes, their status
and operational parameters, because it is responsible of what they do,
starting from setting the user:group they run under. Daemons should
behave the same no matter under what monitor they are running under,
they are not to care about this. This is one of the reasons systemd is
bad. Still, the monitor does the monitoring.


>> A driver does not care if the traffic light is
>> red or green? The street police does.
> This is not as a suitable metaphor as you think it is.

It is, no matter what you think about it.


Alessandro