Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
The Politics of systemd
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Thu Jun 05, 2014 6:02 pm    Post subject: Reply with quote

Anon-E-moose wrote:
genstorm wrote:
Anon-E-moose wrote:
So it's not really clear "when emerging" WTF is really going on.

There's even a news item now so there's not really an excuse to not understand the issue.


A/o this morning when I synced, I haven't seen a "news item" referencing upower.


It only displays when you have it installed.

Anon-E-moose wrote:
And as I said the non-arch version still wants to pull in systemd.
Which means running an ~amd64 pkg, for which you've given people grief before.


There is nothing wrong with that; at least to me, an ~amd64 user.

It is just the case here that the old branch needs systemd, whereas the new branch doesn't; the old branch is well supported by reverse dependencies, the new branch reverse dependencies still need to migrate to.
Back to top
View user's profile Send private message
mrbassie
Apprentice
Apprentice


Joined: 31 May 2013
Posts: 244

PostPosted: Thu Jun 05, 2014 6:03 pm    Post subject: Reply with quote

thanks again, I'll try both.
Why is this sort of thing happening though and why is it being tolerated nay encouraged? If Thompson and Ritchie are Engels and Marx and Stallman is Lenin and Poettering is Stalin I just hope Torvalds doesn't end up like Trotsky.


Last edited by mrbassie on Thu Jun 05, 2014 6:06 pm; edited 2 times in total
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Thu Jun 05, 2014 6:04 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Who else is to blame for laziness, if not the non-RH DE's.


That was more a reference to upower / systemd; as in the second statement, it was written as blaming themselves instead of us blaming them, I don't see a reason for them to blame themselves. Maybe later, but it's too early to see that; when what is happening in the past months has a negative effect to those DEs, ...

mrbassie wrote:
Why is this sort of thing happening though and why is it being tolerated nay encouraged?


Because if pm-utils slows down development, it slows down development; if UPower needs fixed from pm-utils and it doesn't get those, it'll pick an alternative or drop it; etc... As a consequence, this happenings propagate to distributions, which then propagates to users; both have to tolerate this, and try to do as much possible to limit the consequences. Beyond that, it boils down to encouragement that goes in the opposite direction; someone somewhere needs to step up to take on the work again, it is only that that can turn this whole happening upside down to correct the equation.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2475
Location: Dallas area

PostPosted: Thu Jun 05, 2014 6:23 pm    Post subject: Reply with quote

TomWij wrote:
Anon-E-moose wrote:
genstorm wrote:
Anon-E-moose wrote:
So it's not really clear "when emerging" WTF is really going on.

There's even a news item now so there's not really an excuse to not understand the issue.


A/o this morning when I synced, I haven't seen a "news item" referencing upower.


It only displays when you have it installed.


I assume you mean when "upower" is installed.

Quote:
Anon-E-moose wrote:
And as I said the non-arch version still wants to pull in systemd.
Which means running an ~amd64 pkg, for which you've given people grief before.


There is nothing wrong with that; at least to me, an ~amd64 user.

It is just the case here that the old branch needs systemd, whereas the new branch doesn't; the old branch is well supported by reverse dependencies, the new branch reverse dependencies still need to migrate to.


It doesn't bother me to run ~amd64, I have a few pkgs that are that way, though I go back to non-~amd64 when it becomes stable enough.

I just found it ironic that on the one hand people get given grief for running ~amd64 (and the troubles that sometimes go with it)
and on the other hand thinking that people should automatically move to ~amd64.
It sends out a mixed message, IMO.

Anyway glad it's getting sorted out.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2010)
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2960
Location: The Peanut Gallery

PostPosted: Thu Jun 05, 2014 6:42 pm    Post subject: Reply with quote

warrens wrote:
Say that sysvinit still works with hardware a decade from now, do you think that the upstream projects that we use will still write the init scripts for sysvinit? I don't think that they will. From what I have heard, writing systemd units is easier to do than sysvinit scripts. If that is so, I can see upstream developers writing systemd units and tell the users that run sysvinit to write there own sysvinit scripts. When that happens sysvinit will be dead.

You're confusing sysvinit with sysv-rc (as previously used on debian, and elsewhere.) sysvinit is configured with /etc/inittab, and doesn't do very much at all, besides reaping zombie pids, respawning tty's and switching run-levels.

sysvinit is very useful, imo; and just hands over to whatever you want, usually openrc in Gentoo. It's better to have a simple pid 1, afaic.

Writing openrc initscripts is very easy, ime; runscript provides a very nice setup, so initscripts are a bit like ebuilds, with most of the work done elsewhere, and you only add what you need to. It's perfectly possible to write purely declaratively, but equally you can control whatever you want. (cf: man runscript)

That doesn't mean we should write awful shell; that leads to scripts that are brittle, slow and full of holes, and sometimes a presumption that it's shell's fault.

No one does that with sucky C, perl, python or C++ code: we blame the coder, and either throw it away, patch it or use another impl. We don't blame the language.

Every language has its idioms, and it's perfectly possible to write awful code in any language. openrc is a progression on sysv-rc, based on a completely different worldview than systemd. For me it's far more in line with the rest of *nix and POSIX.

For a start we still have the ability to pick and choose components, which is pretty important if you're building your own distro. I've been told on so many occasions Gentoo gives us the tools to build our own distro, so I'm going to pick the ones which don't close down my options in areas that have nothing to do with them. This is not about some hypothetical notion of choice: ime modularity leads to better software, which is why Unix has prospered and blossomed into the tools used to build the latest One True Way de-jour.

I don't ofc care what anyone else wants to use: why would I? I find all the evangelising, and agenda-driven "gentle" pushes most peculiar.

Good luck all.
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Thu Jun 05, 2014 7:29 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I just found it ironic that on the one hand people get given grief for running ~amd64 (and the troubles that sometimes go with it)
and on the other hand thinking that people should automatically move to ~amd64.
It sends out a mixed message, IMO.


That is for people that mix amd64 and ~amd64, as that is an untested situation; running either amd64 or ~amd64 alone isn't a problem, and needs no griefs.
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 169
Location: Ur-th

PostPosted: Wed Nov 19, 2014 2:45 am    Post subject: Reply with quote

Getting back on topic, it seems that those in SystemD-land have declared Bruce Perens as an enemy:

Bruce Perens wrote:
As you can see, I found out this morning that anyone who criticizes systemd has a character flaw. It's not a technical or policy argument at all. You can't really even start talking about it without being criticized for the tone of your discussion.

This is mad, folks.

Entire thread is here.
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2525
Location: UK

PostPosted: Wed Nov 19, 2014 3:31 am    Post subject: Reply with quote

It's a bit late, but since this topic's sitting here freshly bumped:
steveL wrote:
sysvinit is very useful, imo; and just hands over to whatever you want, usually openrc in Gentoo. It's better to have a simple pid 1, afaic.

Not disagreeing with your general idea, but sysvinit is anything *but* simple.

Those internals are so shockingly bad I'm seriously considering using it as an excuse to take up low-level programming, just to let the world have a *sane* drop in replacement. The first thing I'd do is move all the telinit IPC/job-scheduling code out of PID 1...
_________________
runit-init howto | Overlay
Back to top
View user's profile Send private message
djdunn
l33t
l33t


Joined: 26 Dec 2004
Posts: 709
Location: Arrakis

PostPosted: Wed Nov 19, 2014 5:01 am    Post subject: Reply with quote

it might be complex and have bad internals,

but a known evil is better than an unknown one. sysvinit is unlikely to drastically change or introduce userspace breaking surprises at this point.
_________________
A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.

-The First Law of Mentat
Back to top
View user's profile Send private message
gwr
n00b
n00b


Joined: 19 Nov 2014
Posts: 12

PostPosted: Wed Nov 19, 2014 1:51 pm    Post subject: Reply with quote

This topic seems to be the best place for me to ask a question. Long-time lurker registered just for this!

I have seen people be openly suspicious that systemd is becoming a way for companies to bypass open source licensing by using RPC. I am interested in know how exactly that is the case. Does it allow you to make direct kernel calls that would otherwise require you to link to the GPLed kernel? What other ways does the "RPC is not a function" decision allow for commercial software to bypass licenses? Concrete examples would be helpful. :-)
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2652

PostPosted: Wed Nov 19, 2014 2:31 pm    Post subject: Reply with quote

Here are two quck references I found:

From https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html we have this section:
Quote:
What is the difference between “mere aggregation” and “combining two modules into one program”?
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.


Short answer - the RPC mechanism along with separate address spaces should allow commercial code to aavoid the GPL-contamination, however there is that "communications are intimate enough, exchanging complex internal data structures" clause that could cause problems. It'd be a real pain to see this tested in court, given that judge and jurers would likely not be code-capable.

And another reference, from the "other point of view" http://www.opennms.org/wiki/Commercial_OpenNMS :
Quote:
When applied to OpenNMS, this is taken to mean that if connections are made to the OpenNMS database over a socket using JDBC or ODBC, it is not creating "one program". Also, OpenNMS provides a way to insert events into the system over a socket, as well as using XML RPC to communicate, all of which, if used, should not violate the GPL. If a program or script is used to modify OpenNMS configuration files, or to start and stop OpenNMS by using the main OpenNMS startup script, this wouldn't constitute creating one program. Finally, direct HTTP calls to the OpenNMS webUI should also be valid.


As I said, it's a complex, fuzzy issue, and likely to get worse if ever tested in court. Keep in mind that this year the Supremes are about to decide if an API can be copyrighted, and their entire attitude is legal-based, with next to no knowledge of software development.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
gwr
n00b
n00b


Joined: 19 Nov 2014
Posts: 12

PostPosted: Wed Nov 19, 2014 2:40 pm    Post subject: Reply with quote

Thanks for those examples, that was just what I was looking for.

depontius wrote:

As I said, it's a complex, fuzzy issue, and likely to get worse if ever tested in court. Keep in mind that this year the Supremes are about to decide if an API can be copyrighted, and their entire attitude is legal-based, with next to no knowledge of software development.


So, basically we are going to allow lawyers and MBAs to copyright mathematics. We live in interesting times.
Back to top
View user's profile Send private message
ct85711
Apprentice
Apprentice


Joined: 27 Sep 2005
Posts: 152

PostPosted: Wed Nov 19, 2014 8:32 pm    Post subject: Reply with quote

that's politicians and companies for you, next they'll find some way to charge you for the air that you breath. It's all about money to them, nothing else.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2960
Location: The Peanut Gallery

PostPosted: Thu Nov 20, 2014 6:44 am    Post subject: Reply with quote

steveL wrote:
sysvinit is very useful, imo; and just hands over to whatever you want, usually openrc in Gentoo. It's better to have a simple pid 1, afaic.

Ant P. wrote:
Not disagreeing with your general idea, but sysvinit is anything *but* simple.

OK: let's first establish that you want to make it even simpler than it currently is. Is that correct?

That would of course be directly opposite to the current "modern" approach.
Quote:
Those internals are so shockingly bad I'm seriously considering using it as an excuse to take up low-level programming, just to let the world have a *sane* drop in replacement. The first thing I'd do is move all the telinit IPC/job-scheduling code out of PID 1...

Hmm I don't recall seeing all that much code in there when I looked but it was a while ago.

Let's get specific: paste/bin the code files you want to discuss or critique, that are so "shockingly bad" (links to a repo are fine, too.) If there's stuff to improve, let's do exactly that. (It'd certainly be more fun than discussing yaf lunatic approach from whomever.)

Preferably without throwing the baby out with the bathwater.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2652

PostPosted: Thu Nov 20, 2014 1:56 pm    Post subject: Reply with quote

steveL wrote:
steveL wrote:
sysvinit is very useful, imo; and just hands over to whatever you want, usually openrc in Gentoo. It's better to have a simple pid 1, afaic.

Ant P. wrote:
Not disagreeing with your general idea, but sysvinit is anything *but* simple.

OK: let's first establish that you want to make it even simpler than it currently is. Is that correct?


I made a suggestion along this line on one of the other systemd threads... I suggest that PID1 does even less - it basically only waits for death-signals from processes.

At boot time have PID1 fork another process that brings the system up. In addition, I wanted to have PID1 fork yet another process which contains at least some of the intelligence for daemon management. PID1 would know that the daemon died, and would tell its helper, which would figure out what to do. Oh, and have PID1 fork shutdown/reboot processes, too. Really PID1 would only know how to:
1 - Fork another process for daemon management, restarting (configurable) if needed.
2 - Fork processes for startup/shutdown/reboot.
3 - Listen for signals and notify the daemon manager.

(I know some might not like the auto-restart suggested in #1. A default action might be to simply remove a PID file, if no daemon manager is present. Obviously the location of the PID file would have to be standardized, so it could always be found.)
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2960
Location: The Peanut Gallery

PostPosted: Thu Nov 20, 2014 2:06 pm    Post subject: Reply with quote

steveL wrote:
OK: let's first establish that you want to make it even simpler than it currently is. Is that correct?

depontius wrote:
I made a suggestion along this line on one of the other systemd threads... I suggest that PID1 does even less - it basically only waits for death-signals from processes.

Yes, and my response hasn't changed. (That's far too limited, in a nutshell.) By all means dig up your post and link it here though, so others have the context, and we don't have to retread the same ground.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2652

PostPosted: Thu Nov 20, 2014 3:33 pm    Post subject: Reply with quote

steveL wrote:
steveL wrote:
OK: let's first establish that you want to make it even simpler than it currently is. Is that correct?

depontius wrote:
I made a suggestion along this line on one of the other systemd threads... I suggest that PID1 does even less - it basically only waits for death-signals from processes.

Yes, and my response hasn't changed. (That's far too limited, in a nutshell.) By all means dig up your post and link it here though, so others have the context, and we don't have to retread the same ground.


My earlier post was next-to-the-bottom, here: http://forums.gentoo.org/viewtopic-t-1003784-postdays-0-postorder-asc-start-125.html

I never saw your response to that post, and still don't. The subthread stayed there for a few posts, then things drifted in another direction, as they always do. However, what I proposed for PID1 was deliberately quite limited, as I believe it should be, with anything more sophisticated pushed into a different piece of code. Even what I suggested as a "daemon manager" I believe should be quite simple, though I'd like to see some sort of out-of-process plug-in or helper architecture, if someone wants to get sophisticated.

As an aside, it may be perfectly possible to keep all of that stuff (except plug-ins/helpers) in a single executable, it would just see how it was called and select the correct code path, and the code path for PID1 would be the short/sweet/simple one.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2960
Location: The Peanut Gallery

PostPosted: Thu Nov 20, 2014 6:16 pm    Post subject: Reply with quote

steveL wrote:
Yes, and my response hasn't changed. (That's far too limited, in a nutshell.) By all means dig up your post and link it here though, so others have the context, and we don't have to retread the same ground.

depontius wrote:
My earlier post was next-to-the-bottom, here: http://forums.gentoo.org/viewtopic-t-1003784-postdays-0-postorder-asc-start-125.html

I never saw your response to that post, and still don't. The subthread stayed there for a few posts, then things drifted in another direction, as they always do.

You mean this one? Nah you raised it in the earlier thread, and we discussed it then. That's why I didn't respond to it the second time round.

If you want to get the number for a post btw, it's in the top left of the post as you view it, the little page icon immediately to the left of "Posted". Also topic links don't need all that cruft in them, even when you don't have a "topic" button to use, such as on IRC.

Consider this: why didn't the original UNIX developers simply do exactly what you're talking about the first time around?
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2652

PostPosted: Thu Nov 20, 2014 6:53 pm    Post subject: Reply with quote

steveL wrote:
Nah you raised it in the earlier thread, and we discussed it then. That's why I didn't respond to it the second time round.


So can you point me back there, I don't remember any more. There's been a lot of water over the systemd bridge.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2525
Location: UK

PostPosted: Thu Nov 20, 2014 9:52 pm    Post subject: Reply with quote

steveL wrote:
Let's get specific: paste/bin the code files you want to discuss or critique, that are so "shockingly bad" (links to a repo are fine, too.) If there's stuff to improve, let's do exactly that. (It'd certainly be more fun than discussing yaf lunatic approach from whomever.)

Okay, so I had reason to figure out how sysvinit's shutdown/reboot commands work to write this script, because it turns out too many things out there are hardcoded to call sysv binaries...

Let's try to follow the logic for a (conceptually) simple shutdown -h now command. Here's someone's github mirror of shutdown.c for reference (with pretty colours and clickable line numbers). This is the abridged version:

  • main() starts at line 476 or so. It's only bookkeeping code, if a bit cluttered and long.
  • At line 752 (still in main), it calls shutdown(NULL). That leads to line 439, which is init_setenv("INIT_HALT", halttype).
  • What does that function do? It sends off a serialized request through /dev/initctl telling PID 1 to set that var in its own process space. Except halttype is null, so it's unset. Note it's not an actual env var on the receiver side, just a C one. The meaning of this action will not become clear later, it just happens.
  • And then at line 440, shutdown execv()'s itself into the command /sbin/init 0.
  • init's main() starts all the way down at the bottom and sends us off to telinit() on line 2740 because we're not PID 1. The only thing that code does is translate the "telinit 0" command line into another initctl message for the other end of the pipe to read and then exits.


All that's just the bare minimum of what I had to understand, to translate it into another init's version: kill(1, SIGCONT). I didn't bother trying to figure out the inittab side of things, or how shutdown scheduling works, but those are part of PID 1 too along with a bunch of other orthogonal things, and they really don't need to be.

After writing/researching all this I got curious and looked at how systemd handles initctl. It's pretty funny to find out my half-assed perl script is about as complete as the code they're shipping to RHEL customers... :)
_________________
runit-init howto | Overlay
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2960
Location: The Peanut Gallery

PostPosted: Fri Nov 21, 2014 4:23 am    Post subject: Reply with quote

steveL wrote:
Nah you raised it in the earlier thread, and we discussed it then. That's why I didn't respond to it the second time round.

depontius wrote:
So can you point me back there, I don't remember any more. There's been a lot of water over the systemd bridge.

No, as I have nfc where in that monster of a thread it was, and it's not my point, so you get to do your own legwork, er clicking. ;)

If you're happy to accept I know what you're talking about, then please just consider the point I raised:
"Why didn't the original UNIX developers simply do exactly what you're talking about the first time around?"

(leaving aside the obvious and wrong answer, that they didn't think of it.)
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2652

PostPosted: Sat Nov 22, 2014 2:38 am    Post subject: Reply with quote

steveL wrote:
steveL wrote:
Nah you raised it in the earlier thread, and we discussed it then. That's why I didn't respond to it the second time round.

depontius wrote:
So can you point me back there, I don't remember any more. There's been a lot of water over the systemd bridge.

No, as I have nfc where in that monster of a thread it was, and it's not my point, so you get to do your own legwork, er clicking. ;)

If you're happy to accept I know what you're talking about, then please just consider the point I raised:
"Why didn't the original UNIX developers simply do exactly what you're talking about the first time around?"

(leaving aside the obvious and wrong answer, that they didn't think of it.)


Sorry, just not finding it, and I did even try: "site:forums.gentoo.org depontius stevel sysv" was quite enlightening, and makes me realize that we're at the head of Niagara Falls watching all of this systemd-induced stuff flow downriver. I did however find this: http://forums.gentoo.org/viewtopic-t-986720-postdays-0-postorder-asc-start-25.html which appears to be the most relevant hit I found. However it doesn't answer your question, so if you could please restate your answer.

In addition I saw the stuff about prctl(PR_SET_CHILD_SUBREAPER) which as you say, should have made most of this PID1 mess go away. The primary exception appeared to be processes that assumed that PID1 had that role. Also when I looked in the discussion, it wasn't clear to me that it was fully accepted into mainline, just into the -mm series. However I just went looking in "/usr/src/linux/kernel/sys.c", and there we find:
case PR_SET_CHILD_SUBREAPER:
me->signal->is_child_subreaper = !!arg2;
break;
case PR_GET_CHILD_SUBREAPER:
error = put_user(me->signal->is_child_subreaper,
(int __user *)arg2);
break;
So not only is the SET_CHILD_SUBREAPER call there, but there's also GET_CHILD_SUBREAPER, so that there's an architected way to find out the correct information.

It was also interesting to see L.P. on this discussion thread, way back in 2011, and it was clearly in a systemd type of context. However it also looks like what they really wanted it for was for running systemd in containers, and thus being the PID1 of that container.

I'm surprised that none of the alternative daemon managers that have been discussed use this syscall - or do they?
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2960
Location: The Peanut Gallery

PostPosted: Sat Nov 22, 2014 8:41 am    Post subject: Reply with quote

steveL wrote:
If you're happy to accept I know what you're talking about, then please just consider the point I raised:
"Why didn't the original UNIX developers simply do exactly what you're talking about the first time around?"

(leaving aside the obvious and wrong answer, that they didn't think of it.)

depontius wrote:
Sorry, just not finding it, and I did even try: "site:forums.gentoo.org depontius stevel sysv" was quite enlightening, and makes me realize that we're at the head of Niagara Falls watching all of this systemd-induced stuff flow downriver. I did however find this: http://forums.gentoo.org/viewtopic-t-986720-start-25.html which appears to be the most relevant hit I found. However it doesn't answer your question, so if you could please restate your answer.

Here it's the last section of this post.

Going from there, you may think "well why not have a kernel-thread running to reap zombies", and that is where the question above comes in. As a programmer, I'd know for a fact that whatever my customer says, there are some decisions you have to take despite what they say; in this case, I'd know for a fact that somewhere down the line, they are going to want to know about those processes in userland, even if currently they say "I don't want them exposed" for whatever reason.

The thing to bear in mind is that every process is only started because the user told us to. If we hide them in the kernel, then userland never gets a chance to do anything with them at all. And that means we've closed off a whole area of functionality, simply by pre-judging the situation.

In this context, userland is like a script, as opposed to a compiled program (the kernel.)
Quote:
In addition I saw the stuff about prctl(PR_SET_CHILD_SUBREAPER) which as you say, should have made most of this PID1 mess go away. The primary exception appeared to be processes that assumed that PID1 had that role.

Do you have an actual use case in mind?

The only thing I can think of is knowing that the "parent" has died (so the child is now an "orphan"), and in such a situation you already know the original ppid when you fork. So just running getpid before you fork enables the child to know this case already.

If it seems like I'm adding complexity, bear in mind the same changes would need to happen in code running under systemdbug, or in fact any code running on a Linux since the prctl came in (3.4) assuming it is in fact performing such a check at all. So I don't see any issue here, yet.
Quote:
So not only is the SET_CHILD_SUBREAPER call there, but there's also GET_CHILD_SUBREAPER, so that there's an architected way to find out the correct information.

Yeah; I did refer to man prctl in the other (part1) thread; that would have told you the above, though it's good that you're looking at code.
Quote:
It was also interesting to see L.P. on this discussion thread, way back in 2011, and it was clearly in a systemd type of context. However it also looks like what they really wanted it for was for running systemd in containers, and thus being the PID1 of that container.

Yeah, thing is if they were any good, at that point the bulb would have gone off, as they realised this meant they didn't need to run all that bloat in pid1 at all, and could keep modularity and coupling minimal, with all the attendant benefits for security and convenience. They should have jumped all over it, and instantly reworked their design. That they didn't simply indicates they're nubs, afaic.

In itself that wouldn't be an issue: after all we all start somewhere. If only they weren't also trashing all the people who wrote the software they use to develop their turds, and the entire industry that came before them: since after all they've accepted that the approach laid out by Thompson, Ritchie et al. is essentially sound, along with the concomitants like text-based protocols and decoupled IPC. As we've clearly heard on several occasions, their marketing campaign predicates its USPs not only on the effects, like "fasterer boot", but also the meme that the "traditionalists" got it all wrong, didn't know what they were talking about, don't "understand the modern situation" etc.

Speaking as someone who's actually read Lions[1] through a couple of times, I can assure you they are 100% wrong on that last point.
Quote:
I'm surprised that none of the alternative daemon managers that have been discussed use this syscall - or do they?

Not that I know of so far.

[1] Highly recommended: "Lions' Commentary on UNIX 6th edition with Source Code" John Lions (Peer-to-Peer)
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2960
Location: The Peanut Gallery

PostPosted: Sat Nov 22, 2014 8:48 am    Post subject: Reply with quote

@Ant. P: Sorry, I'm not ignoring your post: I read the code yesterday, and just letting it go round in my head while I do other stuff.

I don't want to respond without having absorbed it, and what you're saying.
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2525
Location: UK

PostPosted: Sat Nov 22, 2014 3:05 pm    Post subject: Reply with quote

No problem. My post sounds a bit confused and rantish, but that's because I had to go re-read all that code to write it...
_________________
runit-init howto | Overlay
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 4 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum