[MacPorts] #22872: aiccu - daemondo automatically restarts it, the reason why it exists is because something is broken.....

MacPorts noreply at macports.org
Mon Oct 20 06:19:14 PDT 2014


#22872: aiccu - daemondo automatically restarts it, the reason why it exists is
because something is broken.....
-----------------------+-------------------
  Reporter:  jeroen@…  |      Owner:  cr@…
      Type:  defect    |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:  1.8.1
Resolution:            |   Keywords:
      Port:  aiccu     |
-----------------------+-------------------

Comment (by fgp@…):

 Replying to [comment:5 jinn.koriech@…]:

 > daemondo runs in one of two modes: (1) If no stop-cmd is given, daemondo
 > executes start-cmd asyncronously, and tracks the process id; that
 process id
 > is used to signal the daemon for later stop and/or restart. (2) If stop-
 cmd
 > is given, then both start-cmd and stop-cmd are issued syncronously, and
 are
 > assumed to do all the work of controlling the daemon. In such cases
 there is
 > no process id to track. In either mode, restart-cmd, if present, is used
 to
 > restart the daemon. If in mode 1, restart-cmd must not disrupt the
 process id.
 > If restart-cmd is not provided, the daemon is restarted via a stop/start
 > sequence.
 > ...
 > In mode 1 only, daemondo will exit when it detects that the daemon being
 > monitored has exited.
 > }}}
 >
 > Therefore by removing the --stop-cmd and --restart-cmd we can ensure
 daemondo will only start the aiccu daemon once, however if a netchange
 event is detected daemondo ''should'' correctly restart aiccu.

 You have that exactly backwards, I think. If there's only a `--start-cmd`,
 then `daemondo` will assume that the process it launches does not
 daemonize. It will then assume that the daemon has dies as soon as that
 exits -- which, for aiccu in the default configuration, happens
 immediately.

 We '''do''' want `daemondo` to run in mode (2). We don't want it to track
 the `aiccu.wrapper start` process, we want it to trust that aiccu is
 running after it executed that command, and to '''never''' re-execute
 `aiccu start` unless

 1. the network configuration changes, or

 2. `launchctl` is used to stop or start aiccu.

 So that part of the current `org.macports.aiccu.plist` is fine. The part
 that isn't is the part about pidfile handling. Currently,
 `org.macports.aiccu.plist` passes the `--pidfile` and `--pid=fileclean`
 options to `daemondo`. That causes `daemondo` to read the daemon's PID
 from that file, and to assume that the daemon has exited once the
 corresponding process terminates (maybe also if the PID file is deleted --
 documentation on `daemondo` is unfortunately quite scarce). It seems that
 `daemondo` does '''not''' re-execute the `--start-cmd` in that case, but
 it '''does''' seems to exit, causing `launchd` to re-start `daemondo` and
 that new daemondo instance than (of course) executes the `--start-cmd`
 again.

 Setting `--pid=none` should, I think, avoid that. In that case, `daemondo`
 really should have no way of knowing whether `aiccu` is actually running
 or not, and so shouldn't ever have a reason to re-execute `aiccu.wrapper
 start` without user intervention (or a network change being detected),
 which is the behaviour we want.

 For added safety, we should also ensure that `aiccu.wrapper` never exits
 with a non-zero exit code, even if `aiccu start` does. `aiccu start` seems
 to daemonize only after requesting the tunnel configuration from the TIC
 server, so a wrong username or password, for example, '''will''' cause its
 exit code to be non-zero. If that is passed on to `daemondo`, `daemondo`
 might decide to re-run the command - it doesn't seem to do so in my tests,
 but the behaviour in that case isn't documented, so it might change.

 I'll try to create a patch which implementes these changes - could take me
 a while, though, I really haven't much time to spare right now.

-- 
Ticket URL: <https://trac.macports.org/ticket/22872#comment:9>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list