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

[Walter Doekes (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221513#comment-221513 ] 

Walter Doekes commented on ASTERISK-20831:
------------------------------------------

You should use getcwd() instead of getenv("PWD").

> [patch] Restarted Asterisk process remains in original directory despite symlink change
> ---------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20831
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20831
>             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
>         Attachments: chdir-pwd-on-restart.patch
>
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)