Logread blank on master

while trying to diagnose a kernel crash a while back, i disabled log and installed rsyslog. since then i've done a firmware flash off a master build and now logread doesn't show any output. log is enabled as far as i know.

i can't recall now, would i have done something else to disable log in order to get rsyslog to work?

is that on ssh cli or LuCI or both?

There is a known problem in current master that causes i.e. this issue (see post on devel mailing list). According to the mailing list this issue will be fixed quite soon.


The fix for system log has been merged in master.

But like I say in the mailing list, I noticed also that some services did not start on several routers. E.g. collectd and nlbwmon. And surely there were/are other services, too. That symptom remained after the first ubus fix.

I am curious to know if other users experience the same thing with services.

samba4 couldn't be started neither.

In the case of collectd & nlbwmon the following workaround helps and maybe gives a pointer of where to look for the real problem:

diff --git a/net/nlbwmon/files/nlbwmon.init b/net/nlbwmon/files/nlbwmon.init
index 7c51eb444..a943581d2 100755
--- a/net/nlbwmon/files/nlbwmon.init
+++ b/net/nlbwmon/files/nlbwmon.init
@@ -80,8 +80,8 @@ parse_config() {
 start_service() {
        procd_set_param stderr 1
-       procd_set_param command "$PROG"
        procd_set_param nice "$NICEPRIO"
+       procd_set_param command "$PROG"
        config_load nlbwmon
        config_foreach parse_config nlbwmon
diff --git a/utils/collectd/files/collectd.init b/utils/collectd/files/collectd.init
index 89af365c2..4b8d4f835 100644
--- a/utils/collectd/files/collectd.init
+++ b/utils/collectd/files/collectd.init
@@ -342,10 +342,10 @@ start_service() {
+       procd_set_param nice "$NICEPRIO"
        procd_set_param command /usr/sbin/collectd
        procd_append_param command -C "$COLLECTD_CONF"
        procd_append_param command -f # don't daemonize
-       procd_set_param nice "$NICEPRIO"
        procd_set_param stderr 1
        procd_set_param respawn

Interesting, the order of nice and command parameters for procd makes a difference now?

I just wonder how the changes by @ynezz in ubus (or libubox) have impact on procd init script parsing and command messaging for procd itself. Maybe something in ubus messaging gets lost or interpreted differently than earlier, and the command parameter get resetted if "nice" is later????

My guess (and it really is a guess) is that something odd is going on with the blob messaging that is parsed in procd via libubox. Looking at the commit history there, I see a lot more validation taking place, so it could well be that a long standing message assembly bug has been exposed...or maybe a new bug in the parsing/validation has been created :slight_smile:

1 Like

Are you going to publish your findings on the mailing list?

I tested, and you are right, changing the "nice" parameter before "command" in procd init file does indeed fix things.

The same may happen also for some other procd parameter, so this "nice" may just be the tip of the iceberg.

I'm not subscribed to the mailing list - too much traffic for me - I'll nudge @ynezz on irc, though I'm sure he's already aware.

http dns proxy was also not starting as it should.
I am going to do a new build as I have just seen this:

I can confirm it fixes nlbwmon and samba4 not starting issue, logread is also working.