On 18/04/2017 at 15:11, k...@aspodata.se 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
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng