Open p3x-robot opened 4 years ago
I also encounter this issue very often, sometimes, if emit signals a lot, it will overflow. However, this package did not provide a way to set up NO_REPLY_EXPECTED
for signals.
After multiple tests, I found a workaround: create an interface that only has signals. No Methods at all, only signals. Then emitting signals, no this error anymore. I hope it helps others.
Would you help check if this is a bug or not as well?
I also encounter this issue very often, sometimes, if emit signals a lot, it will overflow. However, this package did not provide a way to set up
NO_REPLY_EXPECTED
for signals.After multiple tests, I found a workaround: create an interface that only has signals. No Methods at all, only signals. Then emitting signals, no this error anymore. I hope it helps others.
Would you help check if this is a bug or not as well?
@chenyanming could you show an example how I can create an interface that only has signals?
@chenyanming i am getting an interface eg:
const bus = DBus.getBus('system')
return new Promise((resolve, reject) => {
bus.getInterface('org.freedesktop.systemd1', '/org/freedesktop/systemd1', 'org.freedesktop.systemd1.Manager', (error, manager) => {
if (error) {
return reject(error);
}
resolve(manager);
});
})
how can i create with signals only?
You are accessing the original Bus. I am not sure whether it works or not.
But I found the following case could work:
A
with interfaces A1
and A2
A1_1
to A1
with addSignal
. (If you need to addMethod
, please add it to another interface, for example, A2, the idea is each interface only can have signal, or only has methods, but not the mix.)A1_1
, it would not overflow.Sorry, after a few day tests, the way I mentioned can not work. Would someone suggest the solution?
https://access.redhat.com/discussions/3536621?tour=8 [SOLVED] - systemd version 42.17e cannot handle too many sessions at once according to red hat global support. It ran out of memorey and futhermore crashed the modules org.freedesktop.logind and org.freedesktop.systemd. This problem was bugfixed and an upgrade to systemd 52.17e is recommended. This issue can happen because of "abandoned" user session. You can check with the command -- $ systemctl | grep 'of user'| grep 'abandoned' You can delete session directories $ rm -rf /run/systemd/system/sessionscope Any runtime issues can be fixed by below commands, it will not hamper anything on the system -- $ systemctl daemon-reexec If daemon-reexec fails with timeout then you should try $ kill 1 Kind regards Mario.P
Hello!
How are you? Do you have any info, how to fix this?
Thanks