New issue
Advanced search Search tips

Issue 641695 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

cryptohomed should have a -n, --nodaemon option

Project Member Reported by drcrash@chromium.org, Aug 27 2016

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.
 
Daemonize() is more that just fork. cryptohomed should be properly isolated from the starting process, so let's continue daemonizing it in production.
Not forking can be beneficial for debugging purposes, but we also bring in other subtle differences from production environment. So, it's a double-edged sword for debugging. I'm still hesitant to add it in.
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

Comment 3 by vapier@chromium.org, Aug 30 2016

Labels: OS-Chrome
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.
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.

Comment 5 by vapier@chromium.org, 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.
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
Cc: apronin@chromium.org
Components: OS>Systems
Components: OS>Systems>Security
Cc: zuan@chromium.org
John I think you just added this? 
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