LLT-6736: Add command 'reload' and support SIGHUP by tomasz-kumor · Pull Request #1844 · NordSecurity/libtelio

tomasz-kumor · 2026-06-25T14:49:13Z

Problem

Currently to change the nordvpnlite configuration while the deamon is running we need to stop it, change the config file and restart the daemon.

./nordvpnlite stop
// change config.json file
./nordvpnlite start -c ~/config.json

The packets may leak during this operation.

Solution

This PR doesn't address the packets leak problem yet but prepares a base for future changes.
It introduces:

CLI reload command support
SIGHUP signal support

Both triggers causes the the daemon to restart with a new configuration.

Verification

Happy path verification

CLI reload

nordvpnlite start -c ~/config.json
nordvpnlite status
// change anything in the config.json (i.e. country code/log level)
nordvpnlite reload
nordvpnliste status

SIGHUP signal

nordvpnlite start -c ~/config.json
nordvpnlite status
// change anything in the config.json
kill -HUP $(pidof nordvpnlite)
nordvpnliste status

Daemon does not restart when config.json not changed

nordvpnlite start -c ~/config.json
kill -HUP $(pidof nordvpnlite) // nordvpnlite reload
// check /var/log/nordvpnlite.log if telio daemon did not restart

☑️ Definition of Done checklist

Commit history is clean (requirements)
README.md is updated
Functionality is covered by unit or integration tests

tomaszpatejko · 2026-06-30T12:22:04Z

+1

stalowyjez

Lgtm, just a few minor comments/questions

Needed for config reload so that reload is triggered only when the file actually changes.

Adds CLI Reload command support. Allows the daemon event loop to receive an already-parsed config from the Reload handler.

Adds support for CLI reload command and SIGHUP signal.

Logging reload requires a persistent handle to the subscriber reload layers. This handle is returned from setup_logging so the daemon loop can swap the log writer and filter level on reload.

tomasz-kumor · 2026-07-03T09:23:10Z

@stalowyjez do you have any other comments?

tomasz-grz

Thanks for tackling this, nice work!
Though I'll add some more critical thoughts from my side here..

Also would be nice to see some nat-lab test cases for the reload scenarios (at least the happy path) 🙏

tomasz-grz · 2026-07-03T09:04:08Z

+    mut config: NordVpnLiteConfig,
+    config_file: &ConfigFile,


Could these two be unified? It's not very obvious what are the differences between the two parameters

I was thinking about that but wasn't sure if I should. What is in the ConfigFile describes the config file, path to it and it's hash. NordVpnLiteConfig contains parsed content of a config file. That's why I wasn't sure if I should mix them.

I would personally prefer something like RunningConfig { parsed, path, hash }, but I'm not sure if it would make it more complicated with the borrow checker..

tomasz-grz · 2026-07-03T09:10:16Z


+#[derive(Clone)]
+pub struct ConfigFile {
+    pub path: String,


What do you think about PathBuf for a more ergonomic way of working with owned paths?

tomasz-grz · 2026-07-03T09:23:58Z

-        rt.block_on(daemon::daemon_event_loop(config))
+        rt.block_on(daemon::daemon_event_loop(
+            config,
+            opts.config_path.clone(),


How does this work with relative config and log paths when we detach? (since the daemon changes working directory, either to / or opts.working_directory)

Do we need to convert to canonical paths before detaching?

For log_file_path there is already a statement in readme:

log_file_path - a path to store the daemon's logs, needs be absolute, otherwise will be relative to working-directory when daemonized

I assumed similar rule for config-file.

IMO it make sense that relative path is determined towards the working directory.

yes but the working directory of the daemon changes after it's "detached".
So if you launch nordvpnlite start -c config.json from /home/user/, the daemon later tries to read /config.json on reload, instead of /home/user/config.json.
We probably need to call canonicalize() before passing the config_path into the daemon_event_loop

Yes, you are correct. But is such case, when config file is relative, shouldn't the user launch the app with --working-directory /home/user/? I assumed that we should follow similar logic as for log_file_path

Actually log path is canonicalized when reading the config, but canonicalizing again after detach would result a different path.

Before the changes, the config and log path were resolved only once before "detaching" the daemon.

So if you nordvpnlite start -c config.json from /home/user/, the config is read and parsed from /home/user/config.json.

After nordvpnlite reload
The daemon will try to read the config from /config.json, but since it doesn't exist, it will:

Create a new default config

Since the default config does not contain a valid API token, the daemon will exit with error breaking the VPN connection.

As you mentioned nordvpnlite start -c config.json --working-directory /home/user/ would solve this, provided the user gave the correct --working-directory, IMHO this is not a very smooth and polished user experience.

I'm just pointing this out, If you are already aware and this was a conscious design decision, please document the expected behavior in the read me.

tomasz-grz · 2026-07-03T09:27:05Z

+                    }
+                    Some(Err(e)) => {
+                        error!("Config file changed but failed to parse: {e}");
+                        Err(e)


Would Ok(CommandResponse::Err(e)) here return the error to the client caller?

here is what we get in log file:

2026-07-03T10:59:21.854830Z ERROR nordvpnlite::command_listener: 201: Config file changed but failed to parse: invalid type: unit variant, expected newtype variant at line 12 column 13

Yes but what do you get in the cli calling nordvpnlite reload? And does the daemon keep running the old config?

On CLI I am getting

Error: InvalidResponse("EOF while parsing a value at line 1 column 0")

daemon is not restarted and continues with the old configuration

tomasz-grz · 2026-07-03T09:39:36Z

+    fn hash_bytes(bytes: &[u8]) -> u64 {
+        use std::collections::hash_map::DefaultHasher;
+        use std::hash::{Hash, Hasher};
+        let mut hasher = DefaultHasher::new();
+        bytes.hash(&mut hasher);
+        hasher.finish()
+    }


I wonder how would this approach handle whitespace or formatting changes in the config file?
Would it trigger reload causing a reconnect?

Maybe we could just use PartialEq to compare the pending config against the current config?

With PartialEq the problem is that changes to AdapterType::Custom will not be catch. #1844 (comment)

Adding a whitespace to a file should trigger a reload. At least that was my team intention during this task refinement.

Yes, but that means it will trigger a reconnect -> packet leak, even though nothing changed in the config functionally.
If you are aware of that and the risk is accepted, then it's fine by me.

tomasz-grz · 2026-07-03T13:42:59Z

+        rt.block_on(daemon::daemon_event_loop(
+            config,
+            opts.config_path.clone(),
+            logging_handle,


logging_handle will be dropped inside daemon_event_loop since it's moved here. Could this lead to unflushed logs during teardown?

tomasz-grz · 2026-07-03T13:50:28Z

+    config_path: String,
+    mut logging_handle: logging::LoggingHandle,
+) -> Result<(), NordVpnLiteError> {
+    let mut config_file = ConfigFile::new(config_path);


Looking at this again, this is called after possible detaching of the daemon.

In case of a relative config_path like we already discussed, I suspect the std::fs::read(&path) could already fail when calculating the hash, even before reload is called.

Do you think it would be worth to at least add a log to?

let hash = std::fs::read(&path) .map(|b| Self::hash_bytes(&b)) .unwrap_or(0);

tomasz-kumor force-pushed the kumor/LLT6736_reload branch from 5271577 to c052054 Compare June 26, 2026 07:55

tomasz-kumor temporarily deployed to Internal June 26, 2026 07:55 — with GitHub Actions Inactive

tomasz-kumor changed the title ~~Kumor/llt6736 reload~~ LLT-6736: Add command 'reload' and support SIGHUP Jun 26, 2026

tomasz-kumor force-pushed the kumor/LLT6736_reload branch from c052054 to 4d76ce4 Compare June 29, 2026 07:31

tomasz-kumor temporarily deployed to Internal June 29, 2026 07:31 — with GitHub Actions Inactive

tomasz-kumor force-pushed the kumor/LLT6736_reload branch from 4d76ce4 to 3541688 Compare June 29, 2026 07:56

tomasz-kumor temporarily deployed to Internal June 29, 2026 07:56 — with GitHub Actions Inactive

tomasz-kumor marked this pull request as ready for review June 29, 2026 08:15

tomasz-kumor requested a review from a team as a code owner June 29, 2026 08:15

tomaszpatejko reviewed Jun 30, 2026

View reviewed changes

Comment thread clis/nordvpnlite/src/command_listener.rs

tomaszpatejko reviewed Jun 30, 2026

View reviewed changes

Comment thread clis/nordvpnlite/src/daemon.rs

tomaszpatejko approved these changes Jun 30, 2026

View reviewed changes

tomaszpatejko previously approved these changes Jun 30, 2026

View reviewed changes

stalowyjez reviewed Jun 30, 2026

View reviewed changes

Comment thread clis/nordvpnlite/src/logging.rs Outdated

Comment thread clis/nordvpnlite/src/logging.rs Outdated

Comment thread clis/nordvpnlite/src/daemon.rs Outdated

Comment thread clis/nordvpnlite/src/config.rs

tomasz-kumor requested a review from stalowyjez June 30, 2026 15:31

tomasz-kumor added 6 commits July 2, 2026 10:29

Add config file change detection

a359c87

Needed for config reload so that reload is triggered only when the file actually changes.

Add Reload command to CommandListener

2c0d84e

Adds CLI Reload command support. Allows the daemon event loop to receive an already-parsed config from the Reload handler.

Add reload support

1a0747f

Adds support for CLI reload command and SIGHUP signal.

Add logging reconfiguration

295958a

Logging reload requires a persistent handle to the subscriber reload layers. This handle is returned from setup_logging so the daemon loop can swap the log writer and filter level on reload.

Update reload_service to OpenWRT init script

e69ff54

Document reload command

b16cb31

tomasz-kumor dismissed tomaszpatejko’s stale review via b16cb31 July 2, 2026 08:33

tomasz-kumor force-pushed the kumor/LLT6736_reload branch from 3541688 to b16cb31 Compare July 2, 2026 08:33

tomasz-kumor temporarily deployed to Internal July 2, 2026 08:33 — with GitHub Actions Inactive

tomasz-kumor requested a review from tomasz-grz July 2, 2026 14:12

tomasz-grz reviewed Jul 3, 2026

View reviewed changes

Uh oh!

Conversation

tomasz-kumor commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

Verification

☑️ Definition of Done checklist

Uh oh!

Uh oh!

Uh oh!

tomaszpatejko commented Jun 30, 2026

Uh oh!

stalowyjez left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tomasz-kumor commented Jul 3, 2026

Uh oh!

tomasz-grz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomasz-grz Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tomasz-grz Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomasz-grz Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomasz-grz Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomasz-grz Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomasz-grz Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tomasz-grz Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

tomasz-kumor commented Jun 25, 2026 •

edited

Loading

tomasz-grz left a comment •

edited

Loading

tomasz-grz Jul 3, 2026 •

edited

Loading

tomasz-grz Jul 3, 2026 •

edited

Loading

tomasz-grz Jul 3, 2026 •

edited

Loading

tomasz-grz Jul 3, 2026 •

edited

Loading

tomasz-grz Jul 3, 2026 •

edited

Loading

tomasz-grz Jul 3, 2026 •

edited

Loading

tomasz-grz Jul 3, 2026 •

edited

Loading

tomasz-grz Jul 3, 2026 •

edited

Loading