I have this entry in my agent "Console" when running the "agentupdate" command on a client with "_noagentupdate: true" in my config.json
uncaughtException1: Error: timers.onElapsed() callback handler on 'sendNetworkUpdate()' => TypeError: cannot read property 'toString' of undefined
It seems this error is NOT displayed when "noagentupdate: true" is in the config.json
Yes, I need to look into this. I don't think it's related to how the agent updates at all. On that specific platform, something goes wrong when trying to get the network information. Can you indicate what agent and OS you are using? - Thanks.
Yes, I need to look into this. I don't think it's related to how the agent updates at all. On that specific platform, something goes wrong when trying to get the network information. Can you indicate what agent and OS you are using? - Thanks.
This happens with Windows, FreeBSD, or Linux agents (May affect more but these are the only ones I use). MeshCentral is running on Debian 10.7. Also, when the config.json has the noagentupdate config set as "noagentupdate": true, this message does not display at all. However I am seeing this error across several agents when they try to self-update even without using the agentupdate console command and there is not a noagentupdate config set. I hope that makes sense.
@Ylianst A new twist has just started. When running the agentupdate command on the console of the client the agent does not start back up. I have to manually go to the computer terminal and restart the service. Is this expected behavior?
Which OS and version is the agent running on?
Which OS and version is the agent running on?
OS's are Windows 10 20H2, Windows Server 2012 R2, Debian 10.7 (Buster), FreeBSD 12.1-HBSD (OPNSense Latest)
Which Mesh Server version are you running? I know the latest one has a fix that addressed FreeBSD not being able to restart itself correctly.
Also, if you have Debian Buster running on x86 or x86-64, I fixed a self-restart issue with that too, but @Ylianst hasn't pushed the update for that agent yet. Altho, these fixed I'm talking about are for the service restart console command. You are saying using the agentupdate console command doesn't restart? There was a bug I fixed in the latest meshserver, where when you did agentupdate, on certain flavors of linux, there was about a 15 second delay before the agent restarted.
Which Mesh Server version are you running? I know the latest one has a fix that addressed FreeBSD not being able to restart itself correctly.
@krayon007 MeshCentral v0.7.59
Ok, I did the following on OPNsense.. When you ran agentupdate on yours, did it say restarting via execv() or via service manager?
```
versions
{
"openssl": "1.1.1i",
"duktape": "v2.3.0",
"commitDate": "2021-01-25T22:47:01.000Z",
"commitHash": "bc4c8aa41b30d6c2c6ce29f461999c53346efe23",
"compileTime": "05:35:30, Jan 26 2021"
}
agentupdate
Downloading update from: https://xxx.xxx.com:443/meshagents?id=30
Download complete. HASH verified.
Updating and restarting agent...
Restarting service via execv()
versions
{
"openssl": "1.1.1i",
"duktape": "v2.3.0",
"commitDate": "2021-01-30T21:28:17.000Z",
"commitHash": "b39d7685a319ebe7af04122557354f20ad9d890d",
"compileTime": "06:29:27, Jan 27 2021"
}
Ok, I did the following on OPNsense.. When you ran
agentupdateon yours, did it say restarting via execv() or via service manager?```
versions
{
"openssl": "1.1.1i",
"duktape": "v2.3.0",
"commitDate": "2021-01-25T22:47:01.000Z",
"commitHash": "bc4c8aa41b30d6c2c6ce29f461999c53346efe23",
"compileTime": "05:35:30, Jan 26 2021"
}
agentupdate
Downloading update from: https://xxx.xxx.com:443/meshagents?id=30
Download complete. HASH verified.
Updating and restarting agent...
Restarting service via execv()
versions
{
"openssl": "1.1.1i",
"duktape": "v2.3.0",
"commitDate": "2021-01-30T21:28:17.000Z",
"commitHash": "b39d7685a319ebe7af04122557354f20ad9d890d",
"compileTime": "06:29:27, Jan 27 2021"
restarting via execv()
My OPNsense seems to be much older than yours... I'll see if I can create a newer OPNsense system. I'll do some more testing with Debian Buster, as my buster system is actually a pi, tho I'm not sure if that would make any difference.
My OPNsense seems to be much older than yours... I'll see if I can create a newer OPNsense system. I'll do some more testing with Debian Buster, as my buster system is actually a pi, tho I'm not sure if that would make any difference.
@krayon007 Keep me posted and let me know if you need any other information from me.
Apparently my Debian test system is Debian 9, my buster system is Raspian... I'll create a vanila Debian 10 system for testing...
OK, I figured it out. There was a small error in the meshcore.js
Basically when you run agentupdate, (on linux or freebsd), the created parameter list got GC'ed before it was passed to the OS to restart the process, which is why the process stopped. No agent changes are necessary, just a server update. Ylian said he'll include it in his next push. Apparently some platforms were more aggressive then others with regards to the GC.
On a side note, I built a Debian 10.5.7 VM, that I'll include in my regular testing.
@krayon007 I believe this is fixed as I don't have debian or freebsd agents failing to restart anymore with the agentupdate command
@krayon007 I believe this is fixed as I don't have debian or freebsd agents failing to restart anymore with the
agentupdatecommand
Oh yeah, Ylian told me this morning he included the fix in v0.7.61
This issue was fixed in MeshCentral v0.7.61. Closing