Skip to content

Conversation

@johnelse
Copy link
Collaborator

The two calls to Unix.dup are intended to point stdout and stderr at
/dev/null - this will normally be the case, as Unix.dup will open the
next available file descriptor and stdout/stderr have just been closed.

However, there are many ways this can go wrong - if an open() happens
in another thread it could mean that...

  • nullfd <> Unix.stdin - this is checked for, but there is no error
    handling if this fails
  • one or both of the Unix.dup calls do not point stdout/stderr at
    /dev/null as intended, but instead open new file descriptors.

This change instead uses Unix.dup2 which atomically closes the second
file descriptor and copies it from the first. This also allows the
explicit calls to Unix.close to be removed. Finally, nullfd is closed as
it is not needed after the calls to Unix.dup2.

The two calls to Unix.dup are intended to point stdout and stderr at
/dev/null - this will normally be the case, as Unix.dup will open the
next available file descriptor and stdout/stderr have just been closed.

However, there are many ways this can go wrong - if an open() happens
in another thread it could mean that...

* nullfd <> Unix.stdin - this is checked for, but there is no error
  handling if this fails
* one or both of the Unix.dup calls do not point stdout/stderr at
  /dev/null as intended, but instead open new file descriptors.

This change instead uses Unix.dup2 which atomically closes the second
file descriptor and copies it from the first. This also allows the
explicit calls to Unix.close to be removed. Finally, nullfd is closed as
it is not needed after the calls to Unix.dup2.

Signed-off-by: John Else <john.else@citrix.com>
Signed-off-by: John Else <john.else@citrix.com>
@andyhhp
Copy link

andyhhp commented Apr 25, 2016

The unix bits of this look correct now

@robhoes
Copy link
Member

robhoes commented Apr 25, 2016

The patches look fine, but why are the tests failing?

@johnelse
Copy link
Collaborator Author

Looks like missing camlp4 packages:

#=== ERROR while installing xapi-backtrace.0.3 ================================#
# opam-version 1.2.2
# os           linux
# command      make
# path         /home/travis/.opam/system/build/xapi-backtrace.0.3
# compiler     system (4.02.3)
# exit-code    2
# env-file     /home/travis/.opam/system/build/xapi-backtrace.0.3/xapi-backtrace-9000-0b6103.env
# stdout-file  /home/travis/.opam/system/build/xapi-backtrace.0.3/xapi-backtrace-9000-0b6103.out
# stderr-file  /home/travis/.opam/system/build/xapi-backtrace.0.3/xapi-backtrace-9000-0b6103.err
### stdout ###
# ocaml setup.ml -configure 
### stderr ###
# ocamlfind: Package `sexplib.syntax' not found
# W: Field 'pkg_sexplib_syntax' is not set: Command ''/home/travis/.opam/system/bin/ocamlfind' query -format %d sexplib.syntax > '/tmp/oasis-8dd4f6.txt'' terminated with error code 2
# E: Cannot find findlib package sexplib.syntax
# E: Failure("1 configuration error")
# make: *** [setup.data] Error 1

Signed-off-by: John Else <john.else@citrix.com>
@johnelse johnelse force-pushed the daemonize-fix-race branch from 28382d2 to 9f10c2d Compare April 25, 2016 13:22
@johnelse
Copy link
Collaborator Author

Travis is fixed, jenkins is failing because bigdisk is out of space...

@johnelse johnelse merged commit be2b74c into xapi-project:master Apr 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants