[asterisk-bugs] [JIRA] (ASTERISK-20864) [patch] Restarted Asterisk process remains in original directory despite symlink change

[Rusty Newton (JIRA)]

Rusty Newton created ASTERISK-20864:
---------------------------------------

             Summary: [patch] Restarted Asterisk process remains in original directory despite symlink change
                 Key: ASTERISK-20864
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20864
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Core/General
    Affects Versions: 10.10.1
         Environment: Fedora 17, Linux kernel 3.6.10-2.fc17.x86_64
            Reporter: James Le Cuirot
            Severity: Minor


As noted in a previous bug report, I have successfully been running Asterisk configured with relative directories for easier deployment. This has been working well in itself but I have spotted a problem when combined with a Capistrano-style of deployment. New releases are checked out into a fresh directory and a "current" symlink is then updated to point to this directory before the application is restarted. In the case of Asterisk, I issue "core restart when convenient". The problem is that Asterisk remains pinned to the original release it was started from and any new configuration is therefore not picked up.

I have written a patch against trunk that issues a chdir to $PWD before the final execvp, which allows the symlink to be re-evaluated before the new instance comes up. $PWD is the only place where the symlinked path is stored as the kernel only holds a file descriptor to the real path. $PWD is not guaranteed to be present so obviously this is checked first. I was aware that Asterisk chdirs to / on startup in some cases so I thought maybe I'd also have to check whether this had happened but then I figured it would simply re-execute this code when starting up again anyway. I wasn't sure what to do if chdir fails so I ignored the result. At worst, it'll remain pinned to the old directory if the new one doesn't exist. That seems like a better and more backwards-compatible option than simply dying.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira