cryptohomed should have a -n, --nodaemon option |
|||||
Issue description(Well, --no-daemon but since we already have --noclose and friends with an extra dash, --nodaemon is more consistent with them.) It is not necessary for cryptohomed to fork when launched by upstart, who already forks to exec it. But mainly this would allow for easier debugging without the fork. Alternately, the default could be to not fork and add a -d, --daemon option. This would not be backwards compatible however, and somewhat at odds with the fact that commands with names ending in 'd' *are* expected to be daemons and fork.
,
Aug 29 2016
daemon() with noclose is not very different than fork()! (I'll give you the
chdir("/"), but it has no effect on cryptohomed here, honestly).
https://github.com/lattera/glibc/blob/master/misc/daemon.c
,
Aug 30 2016
mmm, it is more -- you skipped over the setsid that said, cryptohome is launched via upstart, so upstart itself already handles isolating sessions & fd's, so there's no value in calling daemon directly in cryptohome. we should develop a standard behavior/flag for our tools (or perhaps drop them all). some default to backgrounding, some to foregrounding.
,
Aug 30 2016
I know. I figure that it 1/ would be evident in the code I linked 2, and 2/ not really relevant here as you said because of upstart. My main arguments for this CL right now are tradition (most daemons have a no daemon option) and the ability to then debug much more easily w/o forks (maybe why these options were invented initially). For me, really, debugging was the main motivation. This can be separated from 1/ whether we then should change the config file to request no daemonization, and 2/ what we want to do in general.
,
Aug 30 2016
you can't really separate (2) w/out figuring out (2) first. if we decided to go in one direction (--foreground or --daemon), then we'd need to modify/revert your CL. we've got at least 7 projects now using --foreground, and one using --nodaemon.
,
Aug 30 2016
I thought you meant that we had to pick whether all the tools would be run a a daemon or not. Looks like neard got the flag name right ;-) It doesn't matter that much, really, even though I'd prefer the classic name. YA
,
Jul 27
,
Oct 12
,
Dec 10
John I think you just added this?
,
Dec 11
Yes, and it's already merged, so I guess we can close this one? The only thing that I think I can change in that CL is to change --nodaemonize to --foreground so we have a consistency in flags with other daemons. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by apronin@chromium.org
, Aug 29 2016