
How Tmux Starts Up: An Adventure with Linux Tools (2014) - pcr910303
http://blog.chaselambda.com/2014/11/25/how-tmux-starts-up-an-adventure-with-linux-tools.html
======
ciupicri
> I got the tmux source running (I suggest using vagrant and compiling it in a
> virtual machine).

What's with this need of using virtual machines for almost everything? Why
would I need a virtual machine to compile tmux?

~~~
mav3rick
Doesn't want to dirty his home at all ? (Can use a chroot for this?. Maybe
source is unstable and can crash machine ?

~~~
yjftsjthsd-h
If an unprivileged userland program (like tmux) can bring down the whole
machine, we have bigger problems than an unstable user program.

------
ur-whale
The double fork technique is not exactly news, to say the least ... or is the
article about techniques to figure out what a unix binary does?

If the latter, what is the point since the source of every code path is
available, down to the libc code?

I am not seeing the point of this article.

------
caymanjim
tldr: instead of looking at the source to see how tmux daemonizes (spoiler:
the same way everything else does), someone tries a bunch of convoluted
methods to try to log or intercept fork(), and then looks at the source to see
that it daemonizes the way everything else does.

This is slightly informative and clearly the author is learning the basics,
but there's not a lot of there there.

------
sys_64738
This is quite old as init is pretty much replaced by the kitchen sink nowadays
(aka systemd).

FWIW, a double fork so parent exists is the typical way that daemons were
started in the old days. Assume still the like nowadays.

~~~
nikital
I think it's important to distinguish between the concept of the init process
vs specific implementations of the init process.

The article talks about the init process in general (the process that runs as
PID 1 and picks orphaned processes). There are different implementations of
init (such as SysV-style, systemd, Upstart etc) but it doesn't make a
difference for this article.

