Skip to content
  • Michal Schmidt's avatar
    core: add NOP jobs, job type collapsing · e0209d83
    Michal Schmidt authored
    Two of our current job types are special:
    JOB_TRY_RESTART, JOB_RELOAD_OR_START.
    
    They differ from other job types by being sensitive to the unit active state.
    They perform some action when the unit is active and some other action
    otherwise. This raises a question: when exactly should the unit state be
    checked to make the decision?
    
    Currently the unit state is checked when the job becomes runnable. It's more
    sensible to check the state immediately when the job is added by the user.
    When the user types "systemctl try-restart foo.service", he really intends
    to restart the service if it's running right now. If it isn't running right
    now, the restart is pointless.
    
    Consider the example (from Bugzilla[1]):
    
    sleep.service takes some time to start.
    hello.service has After=sleep.service.
    Both services get started. Two jobs will appear:
     hello.service/start  waiting
     sleep.service/start  running
    Then someone runs "systemctl try-restart hello.service".
    
    Currently the try-restart operation will block and wait for
    sleep.service/start to complete.
    
    The correct result is to complete the try-restart operation immediately
    with success, because hello.service is not running. The two original
    jobs must not be disturbed by this.
    
    To fix this we introduce two new concepts:
    - a new job type: JOB_NOP
      A JOB_NOP job does not do anything to the unit. It does not pull in any
      dependencies. It is always immediately runnable. When installed to a unit,
      it sits in a special slot (u->nop_job) where it never conflicts with
      the installed job (u->job) of a different type. It never merges with jobs
      of other types, but it can merge into an already installed JOB_NOP job.
    
    - "collapsing" of job types
      When a job of one of the two special types is added, the state of the unit
      is checked immediately and the job type changes:
      JOB_TRY_RESTART     -> JOB_RESTART or JOB_NOP
      JOB_RELOAD_OR_START -> JOB_RELOAD or JOB_START
      Should a job type JOB_RELOAD_OR_START appear later during job merging, it
      collapses immediately afterwards.
      Collapsing actually makes some things simpler, because there are now fewer
      job types that are allowed in the transaction.
    
    [1] Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=753586
    e0209d83