prompt_prefix not getting correctly picked up dynamically on config changes

[jgarber-cisco]

What happened
I created a ~/.config/shpool/config.toml file, but setting prompt_prefix or keybinding in there has no effect. I've also tried explicitly passing the file with -c or --config-file to no avail. -v and --verbose don't give me any extra detail, either.

prompt_prefix = "testing testing testing"

What I expected to happen
The prompt prefix should have switched to "testing testing testing"

To Reproduce
Steps to reproduce the behavior:

1. Install with cargo
2. Run with a config file in the default location.

echo 'prompt_prefix = "testing testing testing"' > ~/.config/shpool/config.toml
shpool attach test

3. Observe prompt prefix: shpool:test

Version info
shpool 0.9.2

Logs

2025-10-10T16:17:27.010881Z  INFO ThreadId(01) loading config from "/etc/shpool/config.toml"
2025-10-10T16:17:27.010911Z  WARN ThreadId(01) skip reading config file /etc/shpool/config.toml: Os { code: 2, kind: NotFound, message: "No such file or directory" }
2025-10-10T16:17:27.010919Z  INFO ThreadId(01) loading config from "/home/jagarber/.config/shpool/config.toml"
2025-10-10T16:17:27.010969Z  INFO ThreadId(01) starting with config: Config { norc: None, noecho: None, nosymlink_ssh_auth_sock: None, noread_etc_environment: None, nodaemonize: None, nodaemonize_timeout: None, shell: None, env: None, forward_env: None, initial_path: None, session_restore_mode: None, output_spool_lines: None, vt100_output_spool_width: None, keybinding: None, prompt_prefix: Some("testing testing testing"), motd: None, motd_args: None }
2025-10-10T16:17:27.010983Z  INFO ThreadId(01) new: new
2025-10-10T16:17:27.010988Z  INFO ThreadId(01) new:with_debounce: new
2025-10-10T16:17:27.011065Z  INFO ThreadId(01) new:with_debounce: close time.busy=74.4µs time.idle=2.35µs
2025-10-10T16:17:27.011071Z  INFO ThreadId(01) new: close time.busy=83.1µs time.idle=4.77µs
2025-10-10T16:17:27.011074Z  INFO ThreadId(01) watch: new
2025-10-10T16:17:27.011238Z  INFO ThreadId(03) run: new
2025-10-10T16:17:27.011274Z DEBUG ThreadId(03) run: now Instant { tv_sec: 5700642, tv_nsec: 981978283 } select with ddl None
2025-10-10T16:17:27.011284Z DEBUG ThreadId(03) run: addwatch: "/etc/shpool/config.toml"
2025-10-10T16:17:27.011622Z DEBUG ThreadId(03) run: Actually watching /etc, ic Some("shpool")
2025-10-10T16:17:27.011651Z DEBUG ThreadId(03) run: now Instant { tv_sec: 5700642, tv_nsec: 982357676 } select with ddl None
2025-10-10T16:17:27.011652Z  INFO ThreadId(01) watch: close time.busy=576µs time.idle=2.30µs
2025-10-10T16:17:27.011658Z  INFO ThreadId(01) watch: new
2025-10-10T16:17:27.011669Z DEBUG ThreadId(03) run: addwatch: "/home/jagarber/.config/shpool/config.toml"
2025-10-10T16:17:27.011702Z DEBUG ThreadId(03) run: Actually watching /home/jagarber/.config/shpool/config.toml, ic None
2025-10-10T16:17:27.011706Z DEBUG ThreadId(03) run: Force reload since now watching on target file
2025-10-10T16:17:27.011708Z DEBUG ThreadId(03) run: defer config reloading to Some(Instant { tv_sec: 5700643, tv_nsec: 82414967 })!
2025-10-10T16:17:27.011714Z DEBUG ThreadId(03) run: now Instant { tv_sec: 5700642, tv_nsec: 982420469 } select with ddl Some(Instant { tv_sec: 5700643, tv_nsec: 82414967 })
2025-10-10T16:17:27.011718Z  INFO ThreadId(01) watch: close time.busy=58.6µs time.idle=1.79µs
2025-10-10T16:17:27.011739Z  INFO ThreadId(01) daemon already running on "/run/user/9494/shpool/shpool.socket", no need to autodaemonize
2025-10-10T16:17:27.011742Z  INFO ThreadId(01) 

======================== STARTING ATTACH ============================
[...]

[ethanpailes]

Does the problem persist if you restart shpool? We might not be correctly picking up the config dynamically.

[jgarber-cisco]

You're totally right! Didn't realize it was running.

ps aux | grep shpool                                                           
jagarber 1003872  7.7  0.0 2482896 10884 ?       Sl   Oct06 446:24 shpool --log-file /run/user/9494/shpool/daemonized-shpool.log --socket /run/user/9494/shpool/shpool.socket daemon

Killed 1003872 and re-ran and it picked up my config. Should I close? Improve documentation? Make a subcommand to kill the daemon?

[ethanpailes]

We have a file watcher, and there is no reason that for new shells we shouldn't be pick this config change up, so let's leave it open. We're probably just caching the config value in memory when we shouldn't be

[ethanpailes]

I just took a closer look at the code, and it actually does look like we are correctly reading the prompt prefix from the config store rather than caching it on some in memory data structure that won't be updated on config file changes.

Maybe the problem is in the config watcher itself.