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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox