Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #180107 > unrolled thread

Re: If Linux Is About Choice, Why Then ...

Back to article view | Back to linux.debian.user

Contents

  Re: If Linux Is About Choice, Why Then ... Jonathan de Boyne Pollard <j.deboynepollard-newsgroups@ntlworld.com> - 2017-04-13 22:50 +0200
    Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-13 23:30 +0200
      Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-14 01:30 +0200
        Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-14 11:50 +0200
          Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-15 00:00 +0200
      Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-14 11:00 +0200
        Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-14 11:50 +0200
          Re: If Linux Is About Choice, Why Then ... tomas@tuxteam.de - 2017-04-14 12:40 +0200
            Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-14 13:10 +0200

#180107 — Re: If Linux Is About Choice, Why Then ...

Nicolas George:
> The process with PID one is the only immortal process on the system, and
> adopts all orphan processes.

Wrong.  Indeed, it was the systemd people who drove the making it wrong.

* https://unix.stackexchange.com/a/177361/5132

[toc] | [next] | [standalone]

#180109

[Multipart message — attachments visible in raw view] — view raw

Le quartidi 24 germinal, an CCXXV, Jonathan de Boyne Pollard a écrit :
> Nicolas George:
> > The process with PID one is the only immortal process on the system, and
> > adopts all orphan processes.

> Wrong.  Indeed, it was the systemd people who drove the making it wrong.

I have no idea what that sentence means.

> * https://unix.stackexchange.com/a/177361/5132

Summary: Linux has a new system call to allow process to register as
adopters for orphan processes.

Ok, Linux has a new mutant power that I did not know about, and half my
sentence was wrong.

Yet, PID 1 is still the only immortal process, unless you have another
new mutant power to produce, and that property is needed to have a
reliable monitoring system. Otherwise, the monitoring process could be
killed, and nobody would notice.

So I stand by my claim: monitoring systems must be anchored at PID 1,
and that makes monitoring part of init's job.

(Immortal, in this context, does not mean that it cannot die: of course,
it can die, but if it does, the kernel panics and the hardware watchdog
reboots it. And of course, it means it cannot be killed by things like
the OOM killer.)

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#180111

On Fri, Apr 14, 2017 at 6:20 AM, Nicolas George <george@nsup.org> wrote:
> Le quartidi 24 germinal, an CCXXV, Jonathan de Boyne Pollard a écrit :
>> Nicolas George:
>> > The process with PID one is the only immortal process on the system, and
>> > adopts all orphan processes.
>
>> Wrong.  Indeed, it was the systemd people who drove the making it wrong.
>
> I have no idea what that sentence means.
>
>> * https://unix.stackexchange.com/a/177361/5132
>
> Summary: Linux has a new system call to allow process to register as
> adopters for orphan processes.

Ick. I hope they don't register directly with pid1.

> Ok, Linux has a new mutant power that I did not know about, and half my
> sentence was wrong.
>
> Yet, PID 1 is still the only immortal process, unless you have another
> new mutant power to produce, and that property is needed to have a
> reliable monitoring system. Otherwise, the monitoring process could be
> killed, and nobody would notice.

Or you could have pid1 monitor only the monitoring process, to keep pid1 simple.

> So I stand by my claim: monitoring systems must be anchored at PID 1,
> and that makes monitoring part of init's job.

Conflicting requirements generally indicates a refactoring is necessary.

Of course, it's possible to refactor things incorrectly.

> (Immortal, in this context, does not mean that it cannot die: of course,
> it can die, but if it does, the kernel panics and the hardware watchdog
> reboots it. And of course, it means it cannot be killed by things like
> the OOM killer.)

pid1 seems to be doing a lot of other things in systemd. Is it
cooperatively multitasking with itself yet? Or have they borrowed
threads to define a new kind of process concept, so that pid1 can
multitask with itself preemptively?

I should go look at the source to see, I suppose, if I could only find
the time. I assume they will eventually recognize that pid1 is doing
too much and start pushing some of the conceptual changes outside
pid1.

I, of course, being superhuman, if I could find someone to fund my
efforts, could solve all these problems without mistake. ;->

Yeah.

Still it can be painful to watch them make the mistakes they are
making. I would want them to be trying different solutions. But if I
back-seat drive over in the Fedora tech lists, it will be distracting
to them, so I back-seat drive over here.

And try not to get into too much of a panic, since that doesn't seem to help.

(If I could find someone to fund my efforts, I would sure like to try
to develop an alternative. Sometimes life is not fair. :-/ )

-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

[toc] | [prev] | [next] | [standalone]

#180119

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 25 germinal, an CCXXV, Joel Rees a écrit :
> > Summary: Linux has a new system call to allow process to register as
> > adopters for orphan processes.
> Ick. I hope they don't register directly with pid1.

I am sorry, but that does not even make sense.

> Or you could have pid1 monitor only the monitoring process, to keep pid1 simple.

Or you could have PID 1 monitor a process that monitors a process that
monitors a process that monitors a process that monitors the monitoring
process.

Sorry, I do not share your religious imperative of keeping PID 1 simple
at the cost of making everything else more complex.

> pid1 seems to be doing a lot of other things in systemd. Is it
> cooperatively multitasking with itself yet? Or have they borrowed
> threads to define a new kind of process concept, so that pid1 can
> multitask with itself preemptively?
> 
> I should go look at the source to see, I suppose

Obviously you find burning straw men more entertaining. Please go ahead,
I will try not to trouble further.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#180143

On Fri, Apr 14, 2017 at 6:46 PM, Nicolas George <george@nsup.org> wrote:
> Le quintidi 25 germinal, an CCXXV, Joel Rees a écrit :
>> > Summary: Linux has a new system call to allow process to register as
>> > adopters for orphan processes.
>> Ick. I hope they don't register directly with pid1.
>
> I am sorry, but that does not even make sense.

Well, this is where the conversation does seem to fall apart.

I'm looking at the problem from the point of view of someone who has
seen the ins and outs of an engineering principle called complexity. I
know enough about complexity to understand that you cannot guarantee
response time without properly constraining certain processes -- or,
perhaps I should say, supported recurring paths of execution, because
you might think I mean a specific entity with a process id on a Unix
system, and systemd itself is an example of a unix system process that
has multiple actual supported recurring paths of execution.

>> Or you could have pid1 monitor only the monitoring process, to keep pid1 simple.
>
> Or you could have PID 1 monitor a process that monitors a process that
> monitors a process that monitors a process that monitors the monitoring
> process.

Talk about strawman arguments.

If you care to listen, I am not saying add process redirection to
process redirection ad infinitum. There are, of course, limits to what
one can do that direction, as well, and caution has to be applied in
constructing the redirections.

What I'm suggesting does require changes to the kernel. In particular,
16 bits of process id is not enough.

How we change that requires some thought, but it is not enough.

Systemd already takes a certain approach. Actually, it appears that
they are trying two, maybe three approaches. Ultimately it will have
to end up being able to resolve the identity of a process at a greater
resolution of 1 in 2^16, and distinguish between processes in
different ways than just the arbitrary distinction between threads and
processes, and the arbitrary distinction between system and user.

> Sorry, I do not share your religious imperative of keeping PID 1 simple
> at the cost of making everything else more complex.

It is easy to call things you don't want to think about "religious".
Doing so doesn't solve any problems.

If I had time, maybe I could construct a demonstration of the problem
of complexity that would make the issues clear.

But the demonstrations do exist already.

>> pid1 seems to be doing a lot of other things in systemd. Is it
>> cooperatively multitasking with itself yet? Or have they borrowed
>> threads to define a new kind of process concept, so that pid1 can
>> multitask with itself preemptively?
>>
>> I should go look at the source to see, I suppose
>
> Obviously you find burning straw men more entertaining. Please go ahead,
> I will try not to trouble further.

Working out the set of possible execution paths that a critical
process can take may look like burning straw men to you, or it may
look like wasting time in strawman arguments to you. It appears to
look like a waste of time to many people in management.

I do hope that what you are saying is that you assume that Poettering
and company at least are walking through an informal analysis of the
execution paths in systemd. (Formal analysis would be preferred.)

Otherwise, your reference in other branches of this conversation to
guarantees better than "most of the time" would seem rather, I hate to
use the word, but there it is -- duplicitous.

-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

[toc] | [prev] | [next] | [standalone]

#180118

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 13, 2017 at 11:20:02PM +0200, Nicolas George wrote:

[...]

> Yet, PID 1 is still the only immortal process, unless you have another
> new mutant power to produce, and that property is needed to have a
> reliable monitoring system. Otherwise, the monitoring process could be
> killed, and nobody would notice.

You keep repeating this misconception. "Could be" "nobody would". By your
logic, Apache and PostgreSQL (among many following this model) wouldn't
work. They do. Pretty reliably, at that.

Don't get me wrong: I think SysV gave up on something BSD init had,
and think it should (and could, in fact) re-gain it, but... it's not
as dramatic as (the less informed) systemd proponents would make you
believe.

Systemd has its strengths. If you managed to concentrate on those,
you would do systemd a bigger service. Spreading FUD, by contrast,
does it a disservice.

Regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljwjn8ACgkQBcgs9XrR2kZgCwCdFJP5Gd9EVsvDSHMepS0K5d8F
eY4An0gimfOX8hTQ+bhfW8p4CJprIeqq
=L8sI
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#180120

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 25 germinal, an CCXXV, tomas@tuxteam.de a écrit :
> You keep repeating this misconception. "Could be" "nobody would". By your
> logic, Apache and PostgreSQL (among many following this model) wouldn't
> work. They do. Pretty reliably, at that.

I am sorry, but you are mistaken here, possibly because you have only a
vague idea of what "monitoring system" is exactly about.

You see, when people talk about "monitoring systems", they are not after
"pretty" reliable, they are after PERFECTLY reliable. They want
reliability even against million-to-one coincidences.

(With the default kernel configuration, "being killed due to a stale PID
file" is a 1/65535 coincidence, much higher than million-to-one, except
in Discworld logic.)

Since perfectly is not possible, they settle for as-much-as-possible.
And SysV init is very far from achieving the optimum.

Look at the process hierarchy of your SysV-init-based system: Apache and
PostgreSQL are direct children of PID 1, but PID 1 does not know about
them. If they exit, PID 1 will reap them, but nothing more. There are
many reasons that can cause that: OOM killer, bug in the program,
hardware problems, stale PID file, admin mistake, etc. Some of them will
leave more or less discreet traces in the logs, but not all of them. And
you may find these reasons unlikely, but when someone interested in
"monitoring systems" hears "unlikely", they understand "possible".

And I can say that it happened to me: I have, not often but not just
once either, found that Apache or another daemon was not running, and
could not find the reason easily.

If you are still not convinced, look at the other serious monitoring
systems: all of them have at least a provision to run as PID 1.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#180122

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Apr 14, 2017 at 11:40:29AM +0200, Nicolas George wrote:
> Le quintidi 25 germinal, an CCXXV, tomas@tuxteam.de a écrit :
> > You keep repeating this misconception. "Could be" "nobody would". By your
> > logic, Apache and PostgreSQL (among many following this model) wouldn't
> > work. They do. Pretty reliably, at that.
> 
> I am sorry, but you are mistaken here, possibly because you have only a
> vague idea of what "monitoring system" is exactly about.

Thanks for you nice, condescending tone. Very much appreciated.

> You see, when people talk about "monitoring systems", they are not after
> "pretty" reliable, they are after PERFECTLY reliable. They want
> reliability even against million-to-one coincidences.

Your condescending tone doesn't really help in keepig a good discussion.

Besides, PERFECTLY, oh, well. ECC RAM. Redundant processors. Formally
validated software.

> (With the default kernel configuration, "being killed due to a stale PID
> file" is a 1/65535 coincidence, much higher than million-to-one, except
> in Discworld logic.)

I never said SysV's PID scheme is a good idea. For me it's "good enough",
but I mentioned enough alternatives. You have to make sure that the
monitor process doesn't die (modulo things which can happen to PID 1
too), and that's pretty feasible whithin a current Linux system (the
OOM killer you mention, for example: PostgreSQL excludes its postmaster
from that; you've to make sure that the monitor process doesn't get
out of control, but that's achieved by keeping it simple and small).

[...]

> And I can say that it happened to me: I have, not often but not just
> once either, found that Apache or another daemon was not running, and
> could not find the reason easily.
> 
> If you are still not convinced, look at the other serious monitoring
> systems: all of them have at least a provision to run as PID 1.

For you, systemd might be the knee's bees: for me it's not, and I think
I've stated my reasons enough. I think we've reached the end of a
productive discussion now.

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljwprsACgkQBcgs9XrR2kb9lQCaAlTF4ATTK7c9JXXpiTrAeOy1
PP8AnjPHNSyQ1YGdVN2ddP/gKRpm79yS
=cf4l
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#180123

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 25 germinal, an CCXXV, tomas@tuxteam.de a écrit :
> Thanks for you nice, condescending tone. Very much appreciated.

I am sorry you take it that way. It was not meant to, and thinking about
it again, I see nothing condescending in assuming, based on your
statement, that you are not familiar with the obsession of a fringe of
the Libre software developer community.

> Besides, PERFECTLY, oh, well. ECC RAM. Redundant processors. Formally
> validated software.

Well, your irritation made you do something dishonest: ridiculing a
point of my discourse ignoring that I addressed exactly the same issue
in the next paragraph.

> I never said SysV's PID scheme is a good idea. For me it's "good enough",

Well, you realize it is good enough *for you*, there are a lot of people
who consider it not good enough for them.

> but I mentioned enough alternatives. You have to make sure that the
> monitor process doesn't die (modulo things which can happen to PID 1
> too), and that's pretty feasible whithin a current Linux system (the
> OOM killer you mention, for example: PostgreSQL excludes its postmaster
> from that; you've to make sure that the monitor process doesn't get
> out of control, but that's achieved by keeping it simple and small).

You can do all you want, PID 1 is still the only immortal process on the
system.

And if every single daemon must implement workarounds for the
limitations of SysV init, I say this is a seriously flawed design.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web