aeternity · richcarl · Feb 18, 2025 · Apr 22, 2024 · Nov 15, 2024 · Nov 16, 2024
diff --git a/apps/aecore/src/aecore.app.src b/apps/aecore/src/aecore.app.src
@@ -22,6 +22,7 @@
     exometer_core,
     redbug,
     yamerl,
+    setup,
     lager,
     aeutils,
     base58,

diff --git a/apps/aecore/test/aec_mining_tests.erl b/apps/aecore/test/aec_mining_tests.erl
@@ -98,6 +98,7 @@ mine_block_test_() ->
 
 setup() ->
     InitialApps = {running_apps(), loaded_apps()},
+    {ok, _} = application:ensure_all_started(setup),
     {ok, _} = application:ensure_all_started(aeutils),
     aec_test_utils:mock_fast_and_deterministic_cuckoo_pow(),
     aec_test_utils:start_chain_db(),

diff --git a/apps/aecore/test/aec_target_tests.erl b/apps/aecore/test/aec_target_tests.erl
@@ -46,6 +46,7 @@ target_adj_test_() ->
 
 setup() ->
     InitialApps = {running_apps(), loaded_apps()},
+    {ok, _} = application:ensure_all_started(setup),
     {ok, _} = application:ensure_all_started(aeutils),
     meck:new(aec_txs_trees, [passthrough]),
     meck:new(aec_conductor, [passthrough]),

diff --git a/apps/aeutils/src/aeu_logging_env.erl b/apps/aeutils/src/aeu_logging_env.erl
@@ -3,38 +3,51 @@
 -export([adjust_log_levels/0]).
 
 adjust_log_levels() ->
-    expand_lager_log_root(),
+    set_lager_log_root(),
     aeu_env:check_env(
       aeutils,
       [{[<<"logging">>, <<"hwm">>]     , fun set_hwm/1},
        {[<<"logging">>, <<"level">>]   , fun set_level/1}]).
 
 %% See https://github.com/erlang-lager/lager/issues/557
+%% We want to prevent the log directory from moving during runtime. One
+%% possible scenario might be that someone pecks around in an aeternity
+%% node shell, changes the current working directory and forgets to restore
+%% it. If the log_root setting in lager is a relative path (which it is by
+%% default), this would effectively move the log root.
 %% There are different ways to ensure that the log root is a stable
 %% absolute path (once initialized). This could also be done using
 %% sys.config.src (e.g. `{log_root, "${ROOTDIR}/log"}`, but at the time
 %% of writing, `rebar3 ct` doesn't support `sys_config_src`, and it gets messy
 %% to support both types.
 %%
-%% This setup hook code will likely run after lager has started, but it still
-%% fixes the log root for later. One possible scenario might be that someone
-%% pecks around in an aeternity node shell, changes the current working directory
-%% and forgets to restore it. This would effectively move the logical log_root
-%% in lager, if the setting is a relative path (which is the default).
-%%
-expand_lager_log_root() ->
-    case application:get_env(lager, log_root) of
-        {ok, Root} when is_list(Root) ->
-            case filename:pathtype(Root) of
-                relative ->
-                    application:set_env(lager, log_root,
-                                        filename:absname(Root));
-                absolute ->
-                    ok
-            end;
-        _ ->
-            application:set_env(lager, log_root, setup:log_dir())
-    end.
+%% The setup app must be started before lager, so that this setup hook runs
+%% before lager tries to create the log root directory, and thus only
+%% setup's log_dir setting will determine the log directory location.
+
+set_lager_log_root() ->
+    %% We ignore lager's current `log_root` setting - if it was loaded from
+    %% the boot script, it will simply be the default value (typically just
+    %% "log") from the `lager.app.src` file. Instead, `setup` will decide
+    %% the log directory, and we make sure that the path is an absolute
+    %% path after this point. (If setup's `log_dir` env was not set before,
+    %% the call to setup:log_dir() will set it to $HOME/log.<nodename>.)
+    case is_app_running(lager) of
+        true -> exit(lager_started_before_setup);
+        _ -> ok
+    end,
+    Root = setup:log_dir(),
+    case is_tuple(Root) of
+        true -> exit(invalid_setup_log_dir);
+        _ -> ok
+    end,
+    AbsRoot = case filename:pathtype(Root) of
+                  relative -> filename:absname(Root);
+                  absolute -> Root
+              end,
+    %% also ensure that the setting is not reset by load/reload of the apps
+    ok = application:set_env(lager, log_root, AbsRoot, [{persistent, true}]),
+    ok = application:set_env(setup, log_dir, AbsRoot, [{persistent, true}]).
 
 set_hwm(HWM) when is_integer(HWM) ->
     application:set_env(lager, error_logger_hwm, HWM),

diff --git a/apps/aeutils/src/aeutils.app.src b/apps/aeutils/src/aeutils.app.src
@@ -5,6 +5,7 @@
   {applications,
    [kernel,
     stdlib,
+    setup,
     lager,
     gproc,
     jobs,

diff --git a/config/sys.config b/config/sys.config
@@ -161,7 +161,10 @@
                     {mnesia_compatible_aborts, true}]},
 
   {setup, [
+           {verify_directories, false},  % stop setup from creating dirs
            {abort_on_error, true},
+           %% Note: $HOME here means the aeternity directory, not the user home!
+           %% (These variables are a feature of the setup application.)
            {data_dir, "$HOME/data"},
            {log_dir, "$HOME/log"}
           ]}

diff --git a/docs/hacking.md b/docs/hacking.md
@@ -155,9 +155,12 @@ the temporary directory that was created, do:
       variable expansion on the configuration values. E.g., if an application
       `x` has a configuration entry `{log_dir, "$HOME/log"}`, then calling
       `setup:get_env(x, log_dir)` will return something like
-      "/home/username/log". (This only works on variables defined via `setup`
-      itself, not general shell environment variables - `$HOME` is a
-      predefined special case.)
+      "/home/username/log". *This only works on variables defined by `setup`
+      itself, not operating system environment variables. Note in particular
+      that `$HOME` does not mean the current user's home directory - it
+      refers to the `setup` configuration key `{home, Dir}` meaning the
+      root directory of the Aeternity system; if not set, the current
+      directory is used.*
     - Setup has a configuration option `data_dir` which the Aeternity system
       uses to know where its database is located. The directory needs to
       already exist and be populated at system start, else the startup fails.

diff --git a/rebar.config b/rebar.config
@@ -1,4 +1,5 @@
-%% The requirements on the OTP version come mainly from the patches%% for OTP modules - see `otp_patches/` - requiring the version of
+%% The requirements on the OTP version come mainly from the patches
+%% for OTP modules - see `otp_patches/` - requiring the version of
 %% certain OTP applications, e.g. `mnesia`, to be well known in order
 %% for such patches to be applied deterministically.
 %%
@@ -114,8 +115,9 @@
 
 {relx, [{release, { aeternity, "version value comes from VERSION" },
          % sasl is required for the command `aeternity versions` to work,
-         % it is disabled in `sys.config` though.
-         [runtime_tools, sasl, lager, setup, sext, gproc, jobs, lz4, argparse, trace_runner, app_ctrl,
+         % it is disabled in `sys.config` though. Note that setup must be
+         % started before lager
+         [runtime_tools, sasl, setup, lager, sext, gproc, jobs, lz4, argparse, trace_runner, app_ctrl,
           {rocksdb, load}, {mnesia_rocksdb, load}, {mnesia, load}, kache,
           parse_trans, exometer_core, ranch, aeminer, aecore, aeapi, aehttp, enacl, enoise,
           aebytecode, aeserialization, aevm, aechannel, aefate, aemon, aestratum, ecrecover,
-Original file line number
+Diff line change
@@ Expand Up / @@ -22,6 +22,7 @@ @@
         exometer_core,
         redbug,
         yamerl,
+        setup,
         lager,
         aeutils,
         base58,
@@ Expand Down @@