1. 19 Jan, 2018 5 commits
    • start: don't return false when the container's init exits nonzero · eb808539
      Tycho Andersen authored
      This seems slightly counter-intuitive, but IMO it's what we want.
      Basically, ->start() should succeed if the container is spawned correctly
      (similar to how golang's exec.Cmd.Start() returns nil if the thing spawns
      correctly), and users can check error_num (i.e. golang's exec.Cmd.Wait())
      to see how it exited.
      
      This preserves previous behavior, which basically was that start was always
      successful if the thing actually launched. Since we never kept track of
      exit codes, this would always succeed too. Now that we do, it doesn't, and
      this change is required.
      Signed-off-by: 's avatarTycho Andersen <tycho@tycho.ws>
    • remember the exit code from the init process · cd5177e9
      Tycho Andersen authored
      error_num seems to be trying to remember the exit code of the init process,
      except that nothing actually keeps track of it anywhere. So, let's add a
      field to the handler, so that we can keep track of the process' exit
      status, and the propagate it to error_num in struct lxc_container so that
      people can use it.
      
      Note that this is a slight behavior change, essentially instead of making
      error_num always == the return code from start, now it contains slightly
      more useful information (the actual exit status). But, there is only one
      internal user of error_num which I'll fix in later in the series, so IMO
      this is ok.
      Signed-off-by: 's avatarTycho Andersen <tycho@tycho.ws>
    • lxc.init: correctly exit with the app's error code · 4f4530fa
      Tycho Andersen authored
      Based on the comments in the code (and the have_status flag), the intent
      here (and IMO, the desired behavior) should be for init.lxc to propagate
      the actual exit code from the real application process up through.
      Otherwise, it is swallowed and nobody can access it.
      
      The bug being fixed here is that ret held the correct exit code, but when
      it went around the loop again (to wait for other children) ret is
      clobbered. Let's save the desired exit status somewhere else, so it can't
      get clobbered, and we propagate things correctly.
      Signed-off-by: 's avatarTycho Andersen <tycho@tycho.ws>
    • fix lxc_error_set_and_log to match the docs · 19cfa02c
      Tycho Andersen authored
      The documentation for this function says if the task was killed by a
      signal, the return code will be 128+n, where n is the signal number. Let's
      make that actually true.
      
      (We'll use this behavior in later patches.)
      Signed-off-by: 's avatarTycho Andersen <tycho@tycho.ws>
    • start: don't log stop/continue for non-init processes · 3a9e949f
      Tycho Andersen authored
      This non-init forwarding check should really be before all the log messages
      about "init continued" or "init stopped", since they will otherwise lie
      about some process that wasn't init being stopped or continued.
      Signed-off-by: 's avatarTycho Andersen <tycho@tycho.ws>
  2. 17 Jan, 2018 8 commits
  3. 16 Jan, 2018 4 commits
  4. 12 Jan, 2018 1 commit
  5. 09 Jan, 2018 16 commits
  6. 08 Jan, 2018 4 commits
  7. 06 Jan, 2018 1 commit
  8. 05 Jan, 2018 1 commit