i notice that when running something with sudo, the sudo process remains waiting. maybe sudo needs to do something after the process it started gets finished. does anyone know what this is? i can't explore this with strace since sudo is an suid program.

This article may help. https://www.howtoforge.com/#what-is-a-sudo-session

Here's an excerpt.

As a guess, I'd say it's waiting to close the PAM session once the invoked process has completed.

that is quite usual: the parent process is waiting for completion [of the child] if that was not started as background process.

so the sudo process hangs around in the background for a while so future sudo commands (to the same other user?) don't re-prompt for your password. i thought that feature was a file stored in a place users cannot get to.

^ I think post #4 has a simpler, more accurate explanation.

but waiting will still work if sudo were to directly execv() the program it is to run as opposed to using fork() and having that child do execv() (or whatever) plus all the code/work doing the extra waiting. but if there is something else that sudo code running in the user context still needs to do, that would justify the extra stuff.

my own programming philosophy is "if it's not needed, don't do it".

i'm just curious about sudo. i'm curious to know if something justifies what it is doing or it is just doing it because of the way its developer codes things. i tried to think of how i would implement sudo. but i don't have the experience going through all the design to really know,

I just don't understand it. sudo first checks the user, permissions, configs (password if required) and will create the environment for the child process. finally it uses fork and execv (or something similar to start it.
This is how it work: <any process> will do its job and if required uses fork and execv (or something similar) to start child or children. And will wait for the exit code of it (or them). The other way is when the child process is detached.

you can use pstree to see the process tree and all the parent processes are waiting for their children....

Or
are you speaking about using execv without fork? That will destroy the original process and replace it with its child, so in that case the parent has no any chance to continue....

If the uid is switched it is cleaner to fork+wait.
1. the process table reflects where the child process comes from.
2. when the child exits, cleanups can be performed (as the correct user).

This is an argument against systemd. systemd is a smart implementation of a bloated concept.

unless the parent needs to be there, such as doing more after the child exits, i would bypass the fork so the current process is used instead of having another and having the parent wait for the child. i've done a few programs like that in both C and Python.

but some coders just always follow the fork/exec/wait pattern no matter the purpose.

a thing i did a few days ago runs itself in the background then runs "top" in the foreground. the background part has a synchronous timer and sends a SIGWINCH to "top" to have it update without the drift probably caused by it using a classic sleep pattern instead of a synchronous timer (an extra call to peak at the current time). now my "synctop" command stays right on the top of the minute.

the forking was a little odd on this one because it was the parent doing the "execv" call. the child just went into the sync timer loop.

you gotta know what your processes are doing.
.

how is that "cleaner", what is dirty if you don't?


why is that needed? how is that information used?


what cleanups? as which user?

what concept?

i still don't see a cause to do what is not needed. of course, there can be cases where more steps are need, such as an arbitrary requirement to tell the user it is done. the parent waits for the child and makes the announcement. or let the shell keep on waiting for that process it forked that did setuid then execvp (probably does use the vp one). many programs do run suid as root and shell have no trouble waiting on them.

That is ok.
Probably it is true, but this statement is general and actually meaningless/pointless.
Regarding sudo: you need to check the source code and you will understand why it was implemented this way.
Additionally if you think you know a better way you are always free to realize your solution and publish it.

(systemd is a different issue, do not discuss it here)

it was a minor curiosity not worth even getting the source code for. i didn't expect this to be so drawn out. i will just forget about it.

1. Process
Switching the identity with su or sudo is a security act.
E.g. root switches to user1 and catches her keystrokes.
It should be visible what happens.

2. Cleanup
Say the shell created temporary files in /tmp/
After an exec an installed cleanup handler might still work,
but after a UID change it won't run as the original user.

3. systemd
systemd has a "control the world" concept.
First it is a service starter replacing SysV init scripts.
Then it assimilates syslog, cron, network manager.
Then it will assimilate the remaining services.
Then it will assimilate the desktop.
At the end Linux will have two PIDs: 0 for the kernel and 1 for systemd.
When a user logs in, systemd will open a "systemd OS" box.

Ask the developer: https://www.sudo.ws/todd/