[erlang-questions] Issues attaching to an Erlang process after hot code load

[Technion]

Hi Eric,

Thank you for this advise. Simpler yes - and no. I'd rather fix or improve such things where I can.
I can edit PIPE_DIR in my own releases easily enough, and potentially patch rebar to stop defaulting to /tmp in new release runners. I would send a PR, but this feels like a deliberate design so I don't know if it will go anywhere.

I wouldn't start to tackle that however until I have this attach/stop issue under control. I do understand there will still be situations requiring a reboot, but given the feature exists I'd like to be able to use it correctly - given the way things break it doesn't seem "correct" right now.


 ________________________________________
From: Éric Pailleau <eric.pailleau@REDACTED>
Sent: Tuesday, 7 July 2015 3:15 AM
To: Technion
Cc: Erlang Questions
Subject: Re: [erlang-questions] Issues attaching to an Erlang process after hot code load

Hi,
There is no security issues in Erlang. As far there is no security at all...
Once you know this, everything become simpler.
Note a release upgrade may need a VM reboot in some case,  when changing Erlang core libraries or Erlang release.  So "hot code load" does not necessary imply no VM stop.

On your problem, I agree, pipes locations is a problem.
Regards

Le 6 juil. 2015 01:11, Technion <technion@REDACTED> a écrit :
>
> Hi,
>
>
> I have found recently found out that Erlang questions in Stackoverflow earn a person a tumbleweed award
>
>
> Throughout development, I have in general had no issues starting a release, and running "attach". I have however found after performing a hot code load, this functionality appears to break.
>
> I fully documented (https://github.com/technion/erlvulnscan) in the "Hot code upgrade" heading the process I used. This process appears to have worked correctly, however, I then lose the ability to attach, and more importantly, send "stop" commands when I later wish to perform maintenance on this process.
>
>
> Using the old release directory:
>
> $ ./erlvulnscan-1.02/bin/erlvulnscan attach
> escript: Failed to open
> file: /home/technion/erlvulnscan/rel/erlvulnscan-1.02/erts-6.4/bin/nodetool
> Node is not running!
>
> In the new one:
>
> $ ./erlvulnscan-1.03/bin/erlvulnscan attach
> pong
> Can't access pipe
> directory /tmp//home/technion/erlvulnscan/rel/erlvulnscan-1.03/:
> No such file or directory
>
> I did ultimately find I could connect using this command:
>
> $ ./erlvulnscan-1.03/erts-6.4/bin/to_erl
> /tmp/home/technion/erlvulnscan/rel/erlvulnscan-1.02/erlang.pipe.2
>
> However this feels like an absurd workaround - like something is obviously broken to get into this state.
>
> I can kill the process (using the kill command) after which it can be started and stopped without issue, suggesting something was done wrong, or got broken, during the code load process.
>
>
> I'm not sure if it's an Erlangism I should get used to, but the location of these pipes in general feels very unusual. I don't see why an entire directory structure would be recreated under /tmp, I'd expect to either sit under the release' own directory, or one directory deep in /tmp. The fact it's a deterministic file and directory name could lead to security issues.
>
>
>
>
> Any assistance appreciated (any comments on code or general design also appreciated, this is my first Erlang project).