Beams in basho-patches don't take precedence over existing code #126

Closed
dreverri opened this Issue Mar 23, 2012 · 3 comments

Comments

Projects
None yet
5 participants
@dreverri
Contributor

dreverri commented Mar 23, 2012

The code path "lib/basho-patches" was recently added to Riak's start up using the "-pa" flag:

-pa $RUNNER_LIB_DIR/basho-patches \

-pa $RUNNER_LIB_DIR/basho-patches \

-pa $RUNNER_LIB_DIR/basho-patches \

-pa $RUNNER_LIB_DIR/basho-patches \

-pa $RUNNER_LIB_DIR/basho-patches \

Unfortunately, it does not appear that beams in this directory override existing beams. For example, Riak ships with a patched "etop_txt.beam" but on start up code:clash/0 indicates this version is hidden:

/usr/lib/riak/lib/observer-0.9.10/ebin/etop_txt.beam hides /usr/lib/riak/lib/basho-patches/etop_txt.beam

Also, code:which/1 does not show the patched version:

(riak@127.0.0.1)1> code:which(etop_txt).
"/usr/lib/riak/lib/observer-0.9.10/ebin/etop_txt.beam"
@Vagabond

This comment has been minimized.

Show comment Hide comment
@Vagabond

Vagabond Aug 6, 2012

Contributor

I just ran into this. It needs fixing.

Contributor

Vagabond commented Aug 6, 2012

I just ran into this. It needs fixing.

@Vagabond

This comment has been minimized.

Show comment Hide comment
@Vagabond

Vagabond Aug 10, 2012

Contributor

I found out why this happens, RUNNER_LIB_DIR is wrong when we build a package (for local builds it is ./lib, which is correct).

Proof:

riak      2881 45.8 31.9 20680564 10537320 pts/2 Ssl+ Aug07 2137:20 /usr/lib/riak/erts-5.9.1/bin/beam.smp
 -K true -A 64 -W w -- -root /usr/lib/riak -progname riak -- -home /var/lib/riak -- -boot 
/usr/lib/riak/releases/1.2.0/riak -embedded -config /etc/riak/app.config -name riak@10.0.27.22 -setcookie
riak4_2itesting -pa /usr/lib/riak/basho-patches -- console

So you can see that -pa /usr/lib/riak/basho-patches is there

but:


athompson@r1s12:/usr/lib/riak/lib/basho-patches$ ls /usr/lib/riak/basho-patches/
ls: cannot access /usr/lib/riak/basho-patches/: No such file or directory

And in the riak script:

RUNNER_LIB_DIR={{platform_lib_dir}}
...
 -pa $RUNNER_LIB_DIR/basho-patches \

The path should be /usr/lib/riak/lib/basho-patches/

RUNNER_LIB_DIR is used nowhere else in the file, so it should be safe to fix.

This happened with the ubuntu package, have not tested the others, but it also looks broken for the other platforms.

Contributor

Vagabond commented Aug 10, 2012

I found out why this happens, RUNNER_LIB_DIR is wrong when we build a package (for local builds it is ./lib, which is correct).

Proof:

riak      2881 45.8 31.9 20680564 10537320 pts/2 Ssl+ Aug07 2137:20 /usr/lib/riak/erts-5.9.1/bin/beam.smp
 -K true -A 64 -W w -- -root /usr/lib/riak -progname riak -- -home /var/lib/riak -- -boot 
/usr/lib/riak/releases/1.2.0/riak -embedded -config /etc/riak/app.config -name riak@10.0.27.22 -setcookie
riak4_2itesting -pa /usr/lib/riak/basho-patches -- console

So you can see that -pa /usr/lib/riak/basho-patches is there

but:


athompson@r1s12:/usr/lib/riak/lib/basho-patches$ ls /usr/lib/riak/basho-patches/
ls: cannot access /usr/lib/riak/basho-patches/: No such file or directory

And in the riak script:

RUNNER_LIB_DIR={{platform_lib_dir}}
...
 -pa $RUNNER_LIB_DIR/basho-patches \

The path should be /usr/lib/riak/lib/basho-patches/

RUNNER_LIB_DIR is used nowhere else in the file, so it should be safe to fix.

This happened with the ubuntu package, have not tested the others, but it also looks broken for the other platforms.

@ghost ghost assigned jaredmorrow Aug 10, 2012

jaredmorrow pushed a commit that referenced this issue Aug 11, 2012

Jared Morrow
Fix `platform_lib_dir` definition in packages to compare with devrel …
…settings

In devrel and source builds, `platform_lib_dir` gets set to the `lib` directory
that is created by reltool.  In all packages though, this directory is copied
along with the `releases` and `erts-*` directories into the system lib
directory.  So in all packages `platform_lib_dir` gets defined as a
top level directory containing `lib`, `releases`, and `erts-*`.  The `riak`
script attempts to set the load paths based on this `platform_lib_dir`
setting so source builds act differently than package builds.  This change
fixes that inconsistency and defines a new variable `platform_base_dir`
as the new system lib directory.  `platform_lib_dir` is then defined
as `platform_base_dir/lib` to match up with devrel/source builds.

See: basho/riak#126
@jonmeredith

This comment has been minimized.

Show comment Hide comment
@jonmeredith

jonmeredith Aug 16, 2012

Contributor

Fixed.

Contributor

jonmeredith commented Aug 16, 2012

Fixed.

@ghost ghost assigned seancribbs Aug 20, 2012

hmmr pushed a commit that referenced this issue Nov 8, 2016

Fix `platform_lib_dir` definition in packages to compare with devrel …
…settings

In devrel and source builds, `platform_lib_dir` gets set to the `lib` directory
that is created by reltool.  In all packages though, this directory is copied
along with the `releases` and `erts-*` directories into the system lib
directory.  So in all packages `platform_lib_dir` gets defined as a
top level directory containing `lib`, `releases`, and `erts-*`.  The `riak`
script attempts to set the load paths based on this `platform_lib_dir`
setting so source builds act differently than package builds.  This change
fixes that inconsistency and defines a new variable `platform_base_dir`
as the new system lib directory.  `platform_lib_dir` is then defined
as `platform_base_dir/lib` to match up with devrel/source builds.

See: basho/riak#126

hmmr pushed a commit that referenced this issue Nov 8, 2016

Merge pull request #126 from basho/sbv-snmp-traps
add a riak_snmp config block to app.config
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment