Re: [DNG] [OT] files disappearing reproducibly
> Back to the keyboard, I just discovered, that every (GUI) program I > run, is spawned from PID 1. Honestly, I would have expected those to be > child processes of e.g. the display manager or the session manager... That isn't how it starts off, chances are that when you run a program it is spawned (well, forked, err, cloned) by a process that you own (so *not* pid 1). Important is to know that unix requires *almost every* process to have a parent process. You can get this information with getppid (man getppid), and ps will show it to you. One of the reasons for this is to report the exit code to somebody (man wait ; less /usr/include/sysexits.h) to somebody. A process which hasn't had its exit code collected will hang around in a zombie state (Z in the ps listing) - zombie because it is dead, but still occupies a process table entry, which is a finite resource. So: What happens if a parent process goes away ? Well, the kernel reparents the children so that they are now direct children of pid 1, aka init. And that is what thing that makes pid 1 special[1]. It can't crash/exit/hang because then you'd run out of process table entries which means the whole system hangs. Actually linux will move that forward, and have the kernel panic on init exiting - where would it's status code go, anyway ? So pid 1 - init's main job is to wait for all processes which have lost their parent. Init adopts orphan processes. And if you know that you are almost ready to write your own init. It also happens to be why this mailing list exists: init processes can't crash and so should be simple. regards marc [1] There is some fine print - modern linux allows you to delegate this function to other processes, but just because you can does not mean you should. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] files disappearing reproducibly
Florian Zieboll via Dng said on Sat, 19 Feb 2022 18:51:54 +0100
>Back to the keyboard, I just discovered, that every (GUI) program I
>run, is spawned from PID 1.
This is not precisely true. Even though ps ax lists the PPID of the
programs you run is 1, PID1 didn't spawn them. Here's the explanation...
When there's a desire to background a program in such a way that you
can close the parent program without closing the "spawned" program,
without using the problematic nohup, the iconic way to do it is called
"doublefork", which *assigns* the PPID to PID1.
As a doublefork example, the following is the C code my qownbackup
system uses to background the `qownbackup backup` command:
==
#include
#include
int main(int argc, char *argv[]){
pid_t pid = fork();
if(pid < 0){
printf("First fork failed.\n");
perror("First fork failed!");
} else if(pid == 0){
pid = fork();
if(pid < 0){
printf("Second fork failed.\n");
perror("Second fork failed!");
} else if(pid == 0){
execl("./qownbackup.sh", "./qownbackup.sh", "backup", NULL);
}
}
}
==
Aitor can correct any misunderstandings I have, but here goes my
explanation...
First, understand that the fork() function produces a second process,
called "the child", almost completely identical to the first. The
child's program counter is the same as the parent's, so both process
proceed from the point immediately after the fork() function.
The fork() function returns one of three ranges of integers:
* Less than 1 on error.
* Zero if the current process is the child.
* Greater than zero, and in fact the child's PID, if the process is
the parent.
The child of a child is assigned a PPID of 1.
So the first thing is to do one fork, test the return code for error,
and abort if so. If the return code is positive, indicating that this
is the parent, do nothing, so that the parent finishes normally.
But if the return code is zero, this is the first child, so do another
fork. Once again, run the fork() function, and if the return indicate's
that you're a child (of the child the child the original created), do
an exec function to replace yourself with the command you want to
background, in this case "qownbackup backup".
Because it's the child of a child, its PPID is 1. Aitor, I don't think
I've given the complete story, I think there's a dependency on which
process finishes first, and as such I might have a race condition in my
code.
Also, I think I should have done a setsid() after the second fork, and
I should have done something to close stdin, and redirect stdout and
stderr, to a log file or to /dev/null.
The following is the (Python3) doublefork used in my UMENU2 software:
==
#!/usr/bin/python
import sys
import os
if os.fork():
sys.exit(0)
if os.fork():
sys.exit(0)
os.setsid() ### New to 1.9.3, guarantees complete fork
sys.argv.pop(0)
executable = sys.argv[0]
os.execvp(executable, sys.argv)
==
In the preceding, errors aren't handled, so it just does two straight
forks and proceeds only if both return zero. Then it does a setsid(),
which I think my C implementation should have done too, and then exec's
the desired command, just like my C implementation does.
Doubleforking works in pretty much any computer language with the
fork(). You can even do it in bash or dash, but it's not so
straightforward.
SteveT
Steve Litt
March 2022 featured book: Making Mental Models: Advanced Edition
http://www.troubleshooters.com/mmm
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] basic Linux resources
On Sun, 20 Feb 2022 13:11:36 + Antony Stone wrote: > On Sunday 20 February 2022 at 12:57:07, Florian Zieboll via Dng wrote: > > > Dear list, > > > > I just want to share the two most important things I learned > > yesterday: > > > > 1.) I can "delete" files for which I do not have write permissions, > > if the containing directory is writable by me: > > Indeed - this came as a surprise to me when I first found it. > > The explanation is remarkably simple: > > Write permissions on a *file* determine whether you can modify the > *content* of the file. This has nothing to do with the *file name* > (renaming or deleting). > > Write permissions on *the containing directory* determine whether you > can delete or rename files in that contained directory. This is > because a directory is essentially a file with a special type of > content - names and pointers to other files (inodes). Hallo Antony, thank you for this impressively sleek explanation! Can you (or anybody else here) recommend some similarly well-worded resources (a book!) about these very basic principles, that help me getting my fragments of knowledge into the bigger context? As I believe that this topic is worth an own thread, I'll try to start it with a link to the "Dokumentation für Administratoren" of Munich's LiMux project (in german), which focuses on the application layer, but is a real pleasure to read: https://docplayer.org/67158191-Limux-dokumentation-fuer-administratoren-herausgegeben-vom-sachgebiet-linux-client-der-landeshauptstadt-muenchen-version-basisclient-1-1.html Best regards and libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] "post mortem" (was: Popcorn)
On Sunday 20 February 2022 at 12:57:07, Florian Zieboll via Dng wrote: > Dear list, > > I just want to share the two most important things I learned yesterday: > > 1.) I can "delete" files for which I do not have write permissions, if > the containing directory is writable by me: Indeed - this came as a surprise to me when I first found it. The explanation is remarkably simple: Write permissions on a *file* determine whether you can modify the *content* of the file. This has nothing to do with the *file name* (renaming or deleting). Write permissions on *the containing directory* determine whether you can delete or rename files in that contained directory. This is because a directory is essentially a file with a special type of content - names and pointers to other files (inodes). Antony. -- In the Beginning there was nothing, which exploded. - Terry Pratchett Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] "post mortem" (was: Popcorn)
Dear list, I just want to share the two most important things I learned yesterday: 1.) I can "delete" files for which I do not have write permissions, if the containing directory is writable by me: || The system deletes files automatically when their reference || counts drops to zero. The owner of the file doesn't matter. https://superuser.com/questions/369493/ 2.) On logout, the user's processes are not terminated because they had been spawned from a common "ancestor" process, but because they have a common "session id" (SID). As I have not been able to find a detailed documentation of what's happening on quitting a session, I think about writing a summary of the related mechanisms in the pre-systemd world. Thus, I'd like to ask you for hints about related resources, also regarding the "backgrounding" and "detaching" of processes Thank you and libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
