Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, 29 Aug 2015 18:05:47 -0500 Nate Bargmann wrote: > * On 2015 29 Aug 16:14 -0500, Steve Litt wrote: > > > Yeah, that isn't a problem, and shouldn't be a problem. > > Interestingly, in my LUG, the most pro-systemd guys are the > > mega-metal admins administering hundreds of boxes with hundreds of > > Docker containers. These guys are telling me systemd is necessary > > to efficiently manage the Dockers. > > Okay, then the big official unanswered question is why don't RH, > et. al. just target that use case and leave the rest of us alone? Why > does the rest of the ecosystem need this big sucking sound? :-) You know why, Nate. You were on Debian-User in the bad old days. Back in the day, how many times did I get called a conspiracy theorist for answering that question. Three words: 1. Follow 2. the 3. money. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sun, 30 Aug 2015 02:20:41 +0200 Laurent Bercot wrote: > On 29/08/2015 23:11, Steve Litt wrote: > > in my LUG, the most pro-systemd guys are the mega-metal admins > > administering hundreds of boxes with hundreds of Docker containers. > > These guys are telling me systemd is necessary to efficiently manage > > the Dockers. > > They're telling you that because they've been brainwashed with that > idea, and since it's working for them, they're too lazy to try > anything else. But they're wrong. Alpine Linux, for instance, makes > Docker containers a breeze to use, and makes the images a lot smaller. > Alpine is runit-based, and people have also found success running > Docker containers under s6; systemd is very unnecessary, and anyone > pretending it is is either ignorant or malicious. This is very good information. Thanks, SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Fri, 28 Aug 2015 16:47:18 +0100 Dave Turner wrote: > I always thought su was the wrong way to go about things. > Give me sudo every time. How much stuff do you want to put in sudoers? You really want to do what Ubuntu does? > (there are assorted long discussions about su vs sudo out there on > the interweb, let's not repeat them here!) > Just be glad we still have a choice! That's really the crux of it, isn't it. Whether we have a choice. Whether we have the right to say "hey, with my use case, I want to use sudo!" The systemd cabal is trying to take that away. Using my desktop, today I ran a program in lxterminal, and it failed for lack of root. No problem, I ran it with sudo, and that failed because the program wasn't in sudoers. No problem, I did su -c "program name with arguments" and bang, it got done. I sure like that ability, and I'd sure miss it when it's gone. I use it every day. Sometimes I need a root xterm. Now my mama didn't raise no fool, I run X as slitt, not as root. So when I need a root xterm, I run xterm, then run su -. No problem. For now. But Red Hat's working to make it a problem. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: ???su??? command replacement merged into systemd on Fedora Rawhide
On 30/08/2015 04:29, Isaac Dunham wrote: Correction for this: Alpine Linux is OpenRC based. Ah, sorry, I mixed them: it's Void Linux that's runit-based. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] BUG: zombies increase while running netman
Edward Bartolo writes: > OK, poWaitOnExit added and zombies creation has been reduced. However, > I am still getting these: > > 3584 ?00:00:00 kworker/u8:0 > 3586 ?00:00:00 kworker/1:3 > 3588 ?00:00:01 netman > 3623 ?00:00:00 ifdown > 3644 ?00:00:00 kworker/0:0 > 3645 ?00:00:00 kworker/0:3 > 3898 ?00:00:00 ifup > 4142 ?00:00:00 ifdown > 4163 ?00:00:00 kworker/0:4 > 4186 pts/000:00:00 ps > > This means, I have to also add code to the backend to properly clean > up after terminating on every run. > > It looks like the culprit is execl which is used in core_functions.c. > We must add some code to rid ourselves of zombies. The 'culprit' is the program invoking the backend: It's not collecting the exit status of child processes created by it. Hence, the kernel keeps them around forever. In case you really don't care, code creating new processes can set the dispostion of SIGCHLD to SIG_IGN. In case the backend replace itself with another program by doing an exec system call, eg, via execl (one of serveral wrappers for execve), this needs to be done in the front end. Alternatively, the backend can fork and let the new child do the exec while the parent waits for the process to terminate. This will give you access to the exit status of the 'worker' process which might be useful. Since parent and child share the set of open file descriptors, the frontend will still be able to read data written by 'worker' command in the same way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] BUG: zombies increase while running netman
On 08/30/2015 07:40 AM, Edward Bartolo wrote: OK, poWaitOnExit added and zombies creation has been reduced. However, I am still getting these: 3584 ?00:00:00 kworker/u8:0 3586 ?00:00:00 kworker/1:3 3588 ?00:00:01 netman 3623 ?00:00:00 ifdown 3644 ?00:00:00 kworker/0:0 3645 ?00:00:00 kworker/0:3 3898 ?00:00:00 ifup 4142 ?00:00:00 ifdown 4163 ?00:00:00 kworker/0:4 4186 pts/000:00:00 ps Please accept merge request #4 which should fix the issue for the backend executable. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Laurent Bercot writes:
> On 29/08/2015 14:43, Rainer Weikusat wrote:
>> 'su' is not a concept, it's a program.
>
> Okay, let's clarify.
> A program is the implementation of an idea. The idea is often
> unwritten or unspoken, or forgotten, and people will only refer
> to the implementation; but good design always starts with the idea,
> the concept, of what the program is supposed to do.
>
> When Lennart says "su is a broken concept", he's saying "the
> concept behind the su program is not clear or well-defined, and
> it was not a good idea to implement it";
I completely understand that Poettering prefers to write something like
"su is a broken concept" when he really means "What this program does is
not what I'd like it to do and I'd like it to do things it doesn't do
and since it wasn't written by me, it's not working in the way it had
worked had I written the code." But "broken concept" doesn't really make
any sense: Since ideas don't work, they can't be 'broken', ie not or no
longer capable of working.
su is a program supposed to be installed setuid-0 and what it basically
does is
setuid(geteuid());
execlp("/bin/sh", "sh", (void *)0);
ie, it gets rid of any traces of the uid associated with the process
which invoked it and then replaces itself with a shell. In the usual way,
it then kept accumulating other features related to this simple task
which helped other people to get certain things done. It's (AFAIK) no
longer in active development, hence, the current feature set faithfully
mirrors whatever some people considered useful in the early 1990s. In
itself, this is a not a problem, it just means that su is more useful
for certain tasks and less useful for others. The program is certainly
not 'broken', either, as this would mean "the documented behaviour and
the actual behaviour differ in unintended ways".
Considering that 'concepts' can't be broken and that the program isn't
broken, the statement is actually pure posturing devoid of any meaning:
A somewhat technically sounding way to express "I don't care, bugger
off".
[...]
> As you're saying, the correct design is to separate the tasks
> that the su program accomplishes, if one doesn't need a full-
> environment root shell.
I wouldn't calls this "the correct design": It's a design I consider
advantageous because it avoids a situation where a certain program
'organically' acquires some odd feature set which can't be changed in
incompatible ways without affecting existing users and hence basically
turns into a development dead-end.
> But if a full-environment root shell is needed, logging in as
> root works. That's exactly what the "login" _concept_ is.
I'm not aware of any formal definition of "full-environment root shell"
beyond "what the result of logging in as root by interacting with the
following programs ..., ... and ... in the following way ...,
... happens to be". And I don't think such a formal definition would be
useful. OTOH, executing 'the shell of some user' such that it considers
itself a login shell, ie, processes the startup files such a shell is
supposed to process is useful just not a panacea.
Another tinygram doing that:
-
#include
#include
#include
#include
#include
#define DEFAULT_SHELL "/bin/sh"
static char *get_shell(void)
{
struct passwd *pwd;
char *shell;
shell = getenv("SHELL");
if (shell && *shell) return shell;
pwd = getpwuid(getuid());
if (pwd && *pwd->pw_shell) return pwd->pw_shell;
return DEFAULT_SHELL;
}
static char *get_shell_name(char *shell)
{
char *p0, *p1, *name;
p0 = p1 = shell;
while (*p1) {
if (*p1 == '/') p0 = p1 + 1;
++p1;
}
if (!*p0) {
fprintf(stderr, "Don't know what to make of '%s'\n",
shell);
exit(1);
}
name = sbrk((p1 - p0) + 2);
if (!name) {
perror("sbrk");
exit(1);
}
*name = '-';
strcpy(name + 1, p0);
return name;
}
int main(void)
{
char *shell, *name;
shell = get_shell();
name = get_shell_name(shell);
execl(shell, name, (void *)0);
perror("execl");
return 1;
}
--
Invoking this via sudo will result in an 'interactive' root login shell
insofar the shell itself is concerned.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Steve Litt writes: > On Sun, 30 Aug 2015 02:20:41 +0200 > Laurent Bercot wrote: > >> On 29/08/2015 23:11, Steve Litt wrote: >> > in my LUG, the most pro-systemd guys are the mega-metal admins >> > administering hundreds of boxes with hundreds of Docker containers. >> > These guys are telling me systemd is necessary to efficiently manage >> > the Dockers. >> >> They're telling you that because they've been brainwashed with that >> idea, and since it's working for them, they're too lazy to try >> anything else. But they're wrong. Alpine Linux, for instance, makes >> Docker containers a breeze to use, and makes the images a lot smaller. >> Alpine is runit-based, and people have also found success running >> Docker containers under s6; systemd is very unnecessary, and anyone >> pretending it is is either ignorant or malicious. > > This is very good information. Something else you might want to have a look at: http://www.ibuildthecloud.com/blog/2014/12/03/is-docker-fundamentally-flawed ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
* On 2015 30 Aug 02:27 -0500, Steve Litt wrote: > You know why, Nate. You were on Debian-User in the bad old days. Back > in the day, how many times did I get called a conspiracy theorist for > answering that question. > > Three words: > > 1. Follow > 2. the > 3. money. Sigh, yes, I know. I'm still subscribed to the list and, sadly, legitimate concerns are labeled as "trolls". Such behavior tells me that there are some very deep misgivings about the technical superiority of systemd. People having legitimate concerns over the new systemd/udev enforced network interface naming convention (which seems to happen only on a new install of Stretch at this point) were summarily dismissed. It still baffles me why "eth0" is no longer "good enough". Anyone expressing doubt over the new direction seems dismissed as a troll even when questioning in good faith. What no one has made clear in this thread, nor in the one on D-U is will this new systemd functionality require the removal of su or the login package from the repository? - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] BUG: zombies increase while running netman
Merge accepted. Kind regards, Edward. On 30/08/2015, tilt! wrote: > > > On 08/30/2015 07:40 AM, Edward Bartolo wrote: >> OK, poWaitOnExit added and zombies creation has been reduced. However, >> I am still getting these: >> >> 3584 ?00:00:00 kworker/u8:0 >> 3586 ?00:00:00 kworker/1:3 >> 3588 ?00:00:01 netman >> 3623 ?00:00:00 ifdown >> 3644 ?00:00:00 kworker/0:0 >> 3645 ?00:00:00 kworker/0:3 >> 3898 ?00:00:00 ifup >> 4142 ?00:00:00 ifdown >> 4163 ?00:00:00 kworker/0:4 >> 4186 pts/000:00:00 ps >> > > Please accept merge request #4 which should fix the issue for the > backend executable. > > Kind regards, > T. > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] BUG: zombies increase while running netman
I explicitly avoided to use WaitOnExit() to avoid having to use multi-threading which I wanted to avoid. I will try to create a descendant of TThread to use it to Connect and Disconnect but I need to be cautious to avoid complicating the code. On 30/08/2015, Edward Bartolo wrote: > Merge accepted. > > Kind regards, > Edward. > > On 30/08/2015, tilt! wrote: >> >> >> On 08/30/2015 07:40 AM, Edward Bartolo wrote: >>> OK, poWaitOnExit added and zombies creation has been reduced. However, >>> I am still getting these: >>> >>> 3584 ?00:00:00 kworker/u8:0 >>> 3586 ?00:00:00 kworker/1:3 >>> 3588 ?00:00:01 netman >>> 3623 ?00:00:00 ifdown >>> 3644 ?00:00:00 kworker/0:0 >>> 3645 ?00:00:00 kworker/0:3 >>> 3898 ?00:00:00 ifup >>> 4142 ?00:00:00 ifdown >>> 4163 ?00:00:00 kworker/0:4 >>> 4186 pts/000:00:00 ps >>> >> >> Please accept merge request #4 which should fix the issue for the >> backend executable. >> >> Kind regards, >> T. >> > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] su
I don't understand su, and don't want to read his manpage, let's reinvent it poorly: https://github.com/systemd/systemd/pull/1022 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] BUG: zombies increase while running netman
Edward Bartolo writes: > I explicitly avoided to use WaitOnExit() to avoid having to use > multi-threading which I wanted to avoid. I will try to create a > descendant of TThread to use it to Connect and Disconnect but I need > to be cautious to avoid complicating the code. All you need to do is set the disposition of SIGCHLD to SIG_IGN in the frontend. http://www.freepascal.org/docs-html/rtl/baseunix/fpsigaction.html This will work for the backend process itself, including anything invoked from that via execl (or another exec-wrapper). In case the backend creates processes, these will end up orphaned after the backend process exited, hence, they will be re-parented to init which ought to collect the exit status and discard it, so, no zombies will be lingering around. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sun, 30 Aug 2015 13:39:28 +0100 Rainer Weikusat wrote: > Steve Litt writes: > > > On Sun, 30 Aug 2015 02:20:41 +0200 > > Laurent Bercot wrote: > > > >> On 29/08/2015 23:11, Steve Litt wrote: > >> > in my LUG, the most pro-systemd guys are the mega-metal admins > >> > administering hundreds of boxes with hundreds of Docker > >> > containers. These guys are telling me systemd is necessary to > >> > efficiently manage the Dockers. > >> > >> They're telling you that because they've been brainwashed with > >> that idea, and since it's working for them, they're too lazy to try > >> anything else. But they're wrong. Alpine Linux, for instance, makes > >> Docker containers a breeze to use, and makes the images a lot > >> smaller. Alpine is runit-based, and people have also found success > >> running Docker containers under s6; systemd is very unnecessary, > >> and anyone pretending it is is either ignorant or malicious. > > > > This is very good information. > > Something else you might want to have a look at: > > http://www.ibuildthecloud.com/blog/2014/12/03/is-docker-fundamentally-flawed Very nice! SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 30/08/2015 20:54, Steve Litt wrote: http://www.ibuildthecloud.com/blog/2014/12/03/is-docker-fundamentally-flawed Very nice! Note that the article is about the containers' *host*. When people talk about "making systemd work with containers", they're usually meaning running systemd *in* the containers, i.e. they're talking about the containers' *guests*. Guests are the interesting case, because they're the production images, and that's what people want to make as smooth-sailing, and (if possible) small, as possible. That's what we focused on with the s6-overlay project, for instance. I had, naively, never thought that running the Docker daemon under a systemd host would be problematic. It's just a daemon, and systemd can run them, right ? Ha, ha, it would be too simple. The article stupefied me: because the Docker daemon does not conform to systemd's model, it is "fundamentally flawed" ? And they have the balls to ask docker to change models, because *only* systemd is supposed to handle cgroups ? They never wonder whether the problem wouldn't, by chance, come from systemd, that insists on being a global registry of everything on the host and on controlling everything, not allowing daemons to do their own thing. No, systemd is perfect, and the problem obviously comes from Docker. The nerve, hubris and total lack of shame of these people is baffling. And what's even more mind-boggling is that a large part of the community welcomes that attitude with open arms. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
It seems to me that with so much in common GNU/Linux or UNIX use that was so deeply flawed, he/Redhat would have been further ahead to just fork off and create Poettericks or or Poetterdows. I guess the problem with heading in that direction would have be the lack of recognition, his project/operating system seems to have taken advantage of a well established name, Linux and managed to Hijack a large proportion of the userbase. a rather astute strategic and political move when you look at it that way. -Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sun, 30 Aug 2015 16:20:15 -0400 Clarke Sideroad wrote: > It seems to me that with so much in common GNU/Linux or UNIX use that > was so deeply flawed, he/Redhat would have been further ahead to just > fork off and create Poettericks or or Poetterdows. No, because in a head to head showdown where people could alternate between Linux and PoetterGlom, in a year or two Linux would have won on technical merits. They had to wreck Linux before they could proceed with their plan. > > I guess the problem with heading in that direction would have be the > lack of recognition, his project/operating system seems to have taken > advantage of a well established name, Linux and managed to Hijack a > large proportion of the userbase. a rather astute strategic and > political move when you look at it that way. But ask, why does Redhat pay him for this. Redhat can't make money consulting a simple OS that any admin can admin. Follow the money. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 2015-08-31 05:34, Steve Litt wrote: On Sun, 30 Aug 2015 16:20:15 -0400 Clarke Sideroad wrote: It seems to me that with so much in common GNU/Linux or UNIX use that was so deeply flawed, he/Redhat would have been further ahead to just fork off and create Poettericks or or Poetterdows. No, because in a head to head showdown where people could alternate between Linux and PoetterGlom, in a year or two Linux would have won on technical merits. They had to wreck Linux before they could proceed with their plan. I guess the problem with heading in that direction would have be the lack of recognition, his project/operating system seems to have taken advantage of a well established name, Linux and managed to Hijack a large proportion of the userbase. a rather astute strategic and political move when you look at it that way. But ask, why does Redhat pay him for this. Redhat can't make money consulting a simple OS that any admin can admin. Follow the money. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng It's the NSA. Redhat is unsurprising ... debian? ... they must have spent years putting the right people in the right places ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
And all along I thought a "dock" had to do with a place to put program icons on a desktop and that "docker" was a tool to handle it. I've ignored everything about virtual machines except for Virtual Box and QEMU. Evidently, I now have to know that a "container" is a virtual machine. Or is it? Seems like more buzz words for buzz words sake. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] docker/virtualization (was: The show goes on...)
On Sun, Aug 30, 2015 at 09:11:01PM -0500, Nate Bargmann wrote: > And all along I thought a "dock" had to do with a place to put program > icons on a desktop and that "docker" was a tool to handle it. I've > ignored everything about virtual machines except for Virtual Box and > QEMU. > > Evidently, I now have to know that a "container" is a virtual machine. > Or is it? Seems like more buzz words for buzz words sake. Not quite, though close. There are several levels of virtualization: -chroots (a different /, but same resources) -containers (different resources, same kernel handling them; built on "namespaces", so one kernel can have programs with different network, cpu, filesystem, and other resources) -hypervisors (different kernel, but relying on shims to use host OS drivers: Xen and KVM can fall here) -virtual machines (OS runs on "virtual" hardware, but most instructions get executed directly on the processor; Virtual Box, Virtual PC, some Xen/KVM deployments, and Qemu+kqemu fall here) -emulators (every instruction is emulated; Qemu, various arcade emulators, and so on fall here) The difference is that a container is a set of programs on the same kernel, but with all their resources restricted to a subset of what the real hardware has. HTH, Isaac ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] BUG: zombies increase while running netman
WaitOnExit causes the main thread to wait until the backend finishes. This means it will hang the main thread making the GUI irritatingly unresponsive. Thus, the only way out is to use multi-threading. Regarding zombies, these were automatically adopted by the frontend as terminating the latter also reaped all of them. Edward On 30/08/2015, tilt! wrote: > Why does WaitOnExit() imply multithreading? All it does is wait for the > process to exit. > > Best regards, > T. > > Am 30. August 2015 16:57:54 MESZ, schrieb Edward Bartolo > : >>I explicitly avoided to use WaitOnExit() to avoid having to use >>multi-threading which I wanted to avoid. I will try to create a >>descendant of TThread to use it to Connect and Disconnect but I need >>to be cautious to avoid complicating the code. >> >>On 30/08/2015, Edward Bartolo wrote: >>> Merge accepted. >>> >>> Kind regards, >>> Edward. >>> >>> On 30/08/2015, tilt! wrote: On 08/30/2015 07:40 AM, Edward Bartolo wrote: > OK, poWaitOnExit added and zombies creation has been reduced. >>However, > I am still getting these: > > 3584 ?00:00:00 kworker/u8:0 > 3586 ?00:00:00 kworker/1:3 > 3588 ?00:00:01 netman > 3623 ?00:00:00 ifdown > 3644 ?00:00:00 kworker/0:0 > 3645 ?00:00:00 kworker/0:3 > 3898 ?00:00:00 ifup > 4142 ?00:00:00 ifdown > 4163 ?00:00:00 kworker/0:4 > 4186 pts/000:00:00 ps > Please accept merge request #4 which should fix the issue for the backend executable. Kind regards, T. >>> > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] BUG: zombies increase while running netman
> WaitOnExit causes the main thread to wait until the backend finishes.
> This means it will hang the main thread making the GUI irritatingly
> unresponsive. Thus, the only way out is to use multi-threading.
Multithreading is almost always a bad idea, fortunately there
are other options:
Have you considered using waitpid(-1, &status, WNOHANG)
occasionally ?
The proper way is to register a signal handler, set a global
flag in it and do the above at the next convenient time. This can
involve pselect().
while(waidpid(-1, &status, WNOHANG)){
/* do something with the status - programs can fail, notice that */
}
The manual page for waidpid has the information on how to decode the status.
I do not know how pascal works, and if this is an option there.
But if you have a pipe open to a subordinate process, when it
goes away, the pipe also returns eof, which is the point
at which a wait or waitpid can collect the status.
> Regarding zombies, these were automatically adopted by the frontend as
> terminating the latter also reaped all of them.
Almost: They were then adopted by init, which did the wait and then
the zombie process table entries could be cleared.
regards
marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] su
Le 30/08/2015 17:08, Emiliano Marini a écrit : I don't understand su, and don't want to read his manpage, let's reinvent it poorly I use su everyday. If you don't like it, don't use it. If you are afraid of using it by mistyping, alias it. Could we put an end to this thread? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
