How to remotely recover application logs?

We are trying to figure out if there is a built in way to remotely access the device’s log files. We would like to be able to fetch/dump logread content and access it to troubleshoot our devices when physical access is hard or impossible. We contemplated implementing a custom solution, but figured it would be better to ask here if Legato allows it natively. We have not found anything relevant in the documentation so far.

Anyone has an idea regarding this? Thanks!

2 Likes

Bumping this. Anyone knows?

Bumping this again. Anyone?

How about using ssh and/or scp?

Getting logs is not a problem when developing, when we have physical access to the device (ssh / scp). We just use logread, then either dump it in a text file and scp it or we just use logread and display it on screen. The issue is when the device is deployed at clients` sites and we lose USB/ssh/scp access. SSH/scp then cannot be used and we would like to get them OTA, since we have internet connectivity.

It’s my understanding that ssh can be used over the wireless internet if the iptables are set up for it. Entry needed would be similar to this existing entry for ssh over usb:

-A INPUT -i ecm0 -p tcp -m tcp --dport 22 -j ACCCEPT

We decided not to expose the ssh port over the air for security reasons. Any other alternatives? The dropbear version we are running is not really up to date.

Well you could use ssh outbound from a shell script which requires no changes to iptables. If that’s not acceptable either, we have an app on the WP7700 which reads from a UART and sends to a remote server, you could do something similar to read the log files.

root@swi-mdm9x28-wp:~# ip route
default via 100.71.133.252 dev rmnet_data0
100.71.133.248/29 dev rmnet_data0 proto kernel scope link src 100.71.133.251
192.168.2.0/24 dev ecm0 proto kernel scope link src 192.168.2.2
192.168.225.0/24 dev bridge0 proto kernel scope link src 192.168.225.1
root@swi-mdm9x28-wp:~# ssh sdf.org
Host ‘sdf.org’ is not in the trusted hosts file.
(ssh-rsa fingerprint md5 6e:cd:53:4f:75:a1:e8:5b:63:74:32:4f:0c:85:05:17)
Do you want to continue connecting? (y/n) y
root@sdf.org’s password:
root@sdf.org’s password:
ssh: Connection to root@sdf.org:22 exited: Interrupted.
root@swi-mdm9x28-wp:~#

Hi,

What about enabling remote logs in /etc/syslog-startup.conf ? You can use an own log manegment server our use a cloud one like papertrail & co. They might be not free but they have some really great features and for storing the log from a few devices/test phase should not break the bank.

You still have to enable the Otbound UDP 514 port in firewall (I think it is the default ) As far as I know syslog can send the log only in one direction ( buffer, file, remote) so if you enable remote logging you cannot use logread command anymore. But please check this, if it is still so.

Please let us know if you make some progress or find a solution.

Best,
tom

Yeah we considered doing that. One question though, if we sync with a remote server, won’t that eat up all of our mobile data? Or is it possible to only do it on request? We have about 2MB / month currently, which is not much. We considered also writing to a circular buffer on the flash memory but we are worried about the flash life expectancy.

1 Like

@fjanicki It sounds like you want to be able to request the log from the device via the cellular connection. Either by text or via some other TCP based method.

Then you want the device to collect the current log in memory (similar to running logread) pipe that to a file and then upload it to a predefined FTP server or similar? Does that sound about right?

In an OpenAT app I did this and it worked a treat. Send a command to start collection of the log and then send another to stop collection of the log.

However I am unclear how to achieve this with legato? Maybe execute a script that does this for you? I don’t think there is an easy/obvious way to access the content of the log from within/using legato.

Can anyone confirm this or offer a better alternative please? This is why I found this post… I want to do the same thing.

Thanks,
Karl

Hello everyone,

Remote logging can have an impact on your device RAM/Flash resources and security.

syslogd can log over socket (see the -R parameter mentioned on BusyBox - The Swiss Army Knife of Embedded Linux):

So, here is a proposed alternative:

To avoid transferring too large logs, run such command:
# logread -f | gzip > $TimeStamp.log

To care about the Flash device life expectancy: log to RAM (/tmp/*).

If already few RAM-space left: log to Flash, but have this logging OFF by default (exceptions: if and when power-on or power-off sequences needs inspection).
Whatever Flash or RAM storage, the most recent log should replace the oldest one.

If the mobile data connection cannot be established yet, then keep logs in RAM or Flash. Once logs have been uploaded to any cloud, delete them from the device.

As your logs will be large data, protocols like LWM2M/CoAP/MQTT seem not suitable here. Instead, you should HTTPS-transfer them to any server.

If needed, tune your devices firewall (iptables/ip6tables). curl is probably present inside your embedded Linux image.

For remote logging control, SMS delivery is not 100% reliable. You should use Sierra Wireless cloud platform instead:

Medium-size-and-secured data transfers are supported. You can easily operate on N-devices fleet. You could define 1 own small device data/resource, string-typed, that you will use as a cloud-to-device command, with such possible values:

  • set_log_filter (e.g. regular expression or something similar to log - Legato Docs)
  • start_logging
  • stop_logging
  • transfer_logs: to pass an HTTPS URL to the device for the logs uplink transfer

KR.

@fjanicki

I have a similar situation as you in which I would like to collect logs from our devices from time to time. Did you end up correcting a solution to collect your logs?

Thanks,

Hi Darren,

Yes: we created a Legato component for that.
The log request is sent to the device via SMS.
The log component creates a zip with all logs files + data about the state of the device (cm data, sim info, etc.)
This zip is then posted to an HTTPS endpoint.
Really simple and useful.