Ubus CLI and snapshots

@jow -- as some users pointed out, my old way of setting PROCD with ubus from CLI stopped working on recent snapshots:

if I do: ubus call service set "{ \"name\": \"${packageName}\", \"instances\": { \"status\": { \"command\": [ \"/bin/true\" ], \"data\": { \"status\": \"${2}\" }}}}" for some reason it gets deleted when my PROCD-enabled init script terminates.

Adding it manually from CLI after the init script terminated works, so I've resorted to ( sleep 1 && ubus call service set "{ \"name\": \"${packageName}\", \"instances\": { \"status\": { \"command\": [ \"/bin/true\" ], \"data\": { \"status\": \"${2}\" }}}}" | cat & ).

That seems to work, but it's a hack and I'd like to fix the underlying issue. Is it a ubus issue in snapshots or should I modify my code?

Probably related to this commit: https://git.openwrt.org/?p=project/procd.git;a=commit;h=baaf38c5e540b23ba086d94743de860b60c37161

IMHO you shouldn't (mis-)use the procd service object for persistent runtime information in your app - as an alternative approach save all required information directly in a JSON file on tmpfs.

Just my two cents

1 Like

Hey Dirk, thanks for the link, you're probably right on the money as to what's causing the problem.

Creating a file on tmpfs seems to be a bit wasteful comparing to storing a string in PROCD tho.

"Wasteful" in what way? Both methods consume a minimal amount of memory. The json implementation in scripts is pretty straight forward, json parsing in LuCI is quite simple as well ... and you are much more flexible in storing any kind of app-related information.

adblock example excerpt:

	. "/usr/share/libubox/jshn.sh"
        [...]

	> "${adb_rtfile}"
	json_load_file "${adb_rtfile}" >/dev/null 2>&1
	json_init
	json_add_object "data"
	json_add_string "adblock_status" "${status:-"enabled"}"
        [...]
	json_close_object
	json_dump > "${adb_rtfile}"
1 Like

My assumption was that the block-size for tmpfs would still be a lot bigger than a few bytes I need to store.