From: Phillip Susi <psusi@ubuntu.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH] setsid: don't fork
Date: Tue, 19 Nov 2013 14:49:43 -0500 [thread overview]
Message-ID: <528BC0D7.2090006@ubuntu.com> (raw)
In-Reply-To: <20131119180556.GN5572@x2.net.home>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/19/2013 1:05 PM, Karel Zak wrote:
> but why you don't want --wait behavior? It does not change
> anything, but fix the problem with group leader.
I *do* want that behavior, I just think it was supposed to have been
that way all along and which behavior you get should NOT depend on
whether it is a group leader or not.
> IMHO we can make it (--wait) the default (you almost convinced me
> that the default behaviour should be fixed).
Why even have the option then? Does anyone actually want the non wait
behavior? If they have to add a switch to get it, they may as well
just have the shell background the job. Simpler and cleaner than a
switch.
> fork for sleep() and then kill it
Why is that worse than fork then exec? And I thought swapping the
group leader so the parent process can call setsid() was pretty clever ;)
> I'm also not sure if remove --wait is the best way... what about
> people who already use it? (yep, it's release few weeks ago,
> but...)
The longer it stays in, the more people will use it. Best to get rid
of it now if it wasn't such a great idea, otherwise it will be there
forever.
> If I good understand the man page then setsid() caller is session
> and group leader of the *new* session and group. It's probably
> unwanted to make the original group orphaned (without leader),
> because processes in orphaned group get SIGCONT from kernel...
>
> (BTW, SIGCONT is probably what will happen in your version after
> kill(pid) as the sleeping child is group leader, right?)
I think that happens the old way too: as soon as setsid exits after
successfully forking the child, then the group is orphaned. In other
words, both setpgrp() and exit() remove this process from being the
group leader.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSi8DXAAoJEJrBOlT6nu75N+AH/1qyxjdJ2h+nJgN6BhIQ5WfN
SaEbSmVPGFKEFKS3ltVnH+aGfS9WJiQO5DitNewrqOlek3VSvwG3T9WZRmDPjg0M
gSaTPQMVFDIAcMcaUt71AXBEMxHLZUI5rEDLwXraaDT9ISGSGjCNRpfTrwSCwiHY
jUrulunvS0z2WkqyJbHjQZK19Z0waOEvUO7KH8UK/BWqZ2ybCHvCmC1D/uq3K09A
1dmavup13NNbxF7mG80QqdWfm9nN54N1sQ8iPUrzrQyW/6b29aSfUr74JMKbbSzt
Rodimqio/sYpf7iSbMDA4+Gmswh//IANOf9235h8s5LDb1EghSdVzl5ktu+2aLU=
=ZK8O
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2013-11-19 19:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 19:23 [PATCH] setsid: don't fork Phillip Susi
2013-11-19 13:24 ` Karel Zak
2013-11-19 15:01 ` Phillip Susi
2013-11-19 18:05 ` Karel Zak
2013-11-19 19:49 ` Phillip Susi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528BC0D7.2090006@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.