How can I start debug logging via .desktop file/icon

Hello

Sadly I will be going into hospital soon, in order to continue testing of my system I need to be able to set up the ability to start my deepstream app via a desktop icon and have it tee off a log file. So it can be easily started by my partner.

Normally I start the GST_DEBUG=3 logging from terminal, using a .sh like the below

sudo ./start-ds.sh 2>&1 | tee output.log

How do I write a .desktop file that will start deepstream and also have it start a GDT_DEBUG log file.

current .desktop file is:

[Desktop Entry]
Type=Application
Terminal=true
Name=Start DS
Exec=/home/xavier/DS/start-ds.sh

current .sh file is:

#!/bin/bash

$(/home/xavier/DS/ds-app -c /home/xavier/DS/app-config.txt)

exit 0

start-ds.sh (82 Bytes)
Start-DS.desktop (95 Bytes)

Many thanks

Making some guesses here, but typically one can add environment for startup in several different ways. If your command is normally “/home/xavier/DS/start-ds.sh”, then if you want to manually add environment variable “GST_DEBUG=3” just for this start, one could run the command like this:
GST_DEBUG=3 /home/xavier/DS/start-ds.sh
…which should run the command with that variable.

Keep in mind that having a space or multiple arguments might imply a need for quoting. Perhaps (I’m not testing) this would imply (notice the quotes):
Exec="GST_DEBUG=3 /home/xavier/DS/start-ds.sh"

Another possibility, and I don’t know if the icon launch will work with this, is to extend like this for the logging:
Exec="GST_DEBUG=3 /home/xavier/DS/start-ds.sh 2>&1 | tee output.log"
…but possibly this would think the tee command and content is part of the command to exec and would be confused, not sure…give it a try.

One of the biggest problems you might run into would be if the command is not running in a GUI (a terminal running in a GUI is the same as running in a GUI, but forwarding is different). If you are going to have that application running with a monitor then it won’t be an issue, but you might need to adjust if running by some sort of remote command.

Thanks for quick reply,

If I add quotes

Exec="/home/xavier/DS/start-ds.sh 2>&1 | tee output.log"

It won’t start - “there was an error launching the application”
If I don’t include the quotes it starts with logging running (you can see the lines in terminal screen) but does not create the output.log file which I need

Is there another way to group the command as 1 thing? rather than using “…”?

is there a way to make it open a terminal and then write the line as if I was writing it myself?

Or another way to create a desktop icon that can be double clicked?

thanks again

I am thinking that you should modify the “start-ds.sh” script itself, and try without the icon setup itself being the source of logging. You could create this as an alternate name for experimentation, e.g., “start-ds_log.sh”. For reference, try something like this:

#!/bin/bash

$(/home/xavier/DS/ds-app -c /home/xavier/DS/app-config.txt 2>&1 | tee output.log)


exit 0

I created a second .sh

Now I have a .desktop which starts the new .sh that starts the logging

#!/bin/bash

$(sudo ./start-ds.sh 2>&1 | tee $(date '+%Y-%m-%d_%H-%M-%S'.log))

exit 0

and the original .sh which starts deepstream.

thanks

My script worked however when the .log or .txt files get too large deepstream will automatically close

With a txt file it goes to about 2.1gb which takes about 20 hours. 2147488089bytes and 2147488344bytes too similar to be a coincidence

Is there a way to stop this from happening?

If it start the debug myself in terminal it will continue to run even over 16gb

Doesn’t bother my if the log file ends up being enormous as I only want to see the last 250ish lines

Thanks Chris

I don’t know which limit was hit. Perhaps it is part of ulimit (user limits) at 2GB, or perhaps the disk as a whole just ran out of space. From the perspective of why a log file of a certain size fails, more information would be needed.

In terms of limiting the amount of logging itself, so that such a large file is never going to occur, then more information would be needed on how big you want, or when to limit this. If you built your own application, then you’d just write in a log file size handler, but otherwise you might use other methods. Unfortunately I don’t know enough about deepstream to say if it has any of its own logging management, so you’d again need to provide a lot more detail on what it is you want from logs before anyone could say how to keep logs at an appropriate size.

Generally speaking though, since you are redirecting through a pipe, I suspect it shouldn’t be too hard, but it also might not be obvious. The simple (but probably not correct approach without some care) would be to pipe first to “tail -n 250”, and then output that to a file. If you need continuous logging of lines as they occur, then this needs adjustment, but if you don’t mind building up 250 lines, logging that, and then buffering 250 more lines followed by overwriting the original log, this would be simpler. Depends on what you want to accomplish in terms of timing of when you read logs.

Another example case would be to write 250 lines to a log like mentioned above, and then having it rotate and build a second log file of 250 lines. One could pick a number of log files, and then rotate which one to overwrite to. Xorg does this, and if you go to “/var/log”, you’ll see both an Xorg.0.log and an “Xorg.0.log.old”. The dpkg package manager does this in an extended format where it has “dpkg.log”, and then “dpkg.log.1” and “dpkg.log.2.gz”, and increments the gzip compressed one up to “dpkg.log.9.gz” before rotating logs and getting rid of the oldest log ("9") once the max number of log files occur.

thanks for your hep with this, I’ll give these things a try!

Don’t need continuous logging

do I swap tee to tail then add > to output the file

$(sudo ./start-ds.sh 2>&1 | tail -250 output.log > $(date '+%Y-%m-%d_%H-%M-%S'.log))

or will this create 2 .log files: output.log and date.log? The program will still stop when output.log reaches 2.1gb

can I do it without the output.log file?
$(sudo ./start-ds.sh 2>&1 | tail -250 > $(date '+%Y-%m-%d_%H-%M-%S'.log))

These are probably both completely wrong

I wondered if the 2.1gb limit was something to do with bash itself?

thanks again!

I don’t think it will be that simple. Think of what I’m about to write as more or less “pseudo code”, and not literal.

The “tail -n 250” is just an analogy of a function. If you already have a buffer with the right content, then echo of that buffer to “tail -n 250”, followed by redirect to a file would work. Then your app could release any line at the head of the buffer exceeding the already saved 250 lines, followed by appending more lines until it is back up to 500 lines…rinse and repeat to echo the last 250 lines via something like “tail -n 250” of the buffer, and again delete the first 250 lines in the buffer.

Thus the problem with something “simple” is that it needs to accumulate a buffer, recognize when 250 lines are available, and then trigger logging of those 250 lines to a new file name.

When it comes to files in “/var/log” there is a log rotation program. This does not directly switch to a new log name. What it does is recognize the need to move the old file name to a new file name, and then start logging again in the original old file name (which is now empty). This does not switch files in the middle of a log unless it first stops logging and then restarts logging.

There are standardized tools which are used for this more “simplified” log rotation which you could use to trigger rotation just by using what’s already part of Linux logging. Or you could make your script recognize when it has logged 250 lines, and then switch to a new log file. If this also looks to see how many log files you have, then it could remove log files which exceed some chosen count, e.g., it could keep two log files, and if it sees a third created, then delete the one oldest file to leave two log files.

This isn’t really a direct answer, but there are several articles on setting up “standard” log rotations in Ubuntu (mostly this is the same on every distribution, but the Jetson runs Ubuntu, and Mint is very similar):
Search for ubuntu+how+to+rotate+logs

Personally, just because I like things to work the exact way I want, I’d be tempted to spend time to create a bash script (you already have a bash script, just simple) which logs with custom scripting. This isn’t for everyone, especially if you are in a crunch for time, and I am a bit odd that a custom script is somewhat entertaining to build (if I have time).

If you were to use a custom script, then you’d need to specify if the script needs to handle the system shutting down in the middle of running, e.g., from reboot. If you don’t care if reboot loses the last few lines of log, then it is quite simple.

On the more complicated side you could even create a service (systemd) to automatically start your program and handle what to do for truncating versus saving of the last few log lines upon shutdown/reboot. To really answer this you’d need to provide details of what you really require, versus what you would desire, along with whether you have the time to work on something custom. If not enough time or desire, then probably learning how to use the log rotation method which the above URL search is for would be your best bet.

Hi,

I was trying to use logrotate but all of a sudden all my desktop icons changed to documents and now every time I start anything it ask me to trust and launch - it doesn’t remember trust and launch either, even chromium-browser.

Online it suggested using gio “metadata::trusted” but it said “setting attribute metadata::trusted not supported”??

any ideas?

Sorry and thanks so much for you help!

I have not tried this for custom cases. I looked for an example though, and liked this which is specific to Ubuntu 18.04:
https://linoxide.com/setup-log-rotation-logrotate-ubuntu/

One thing is that you might want your log to go to some unused temporary location and not to “~/Desktop” (at least while testing). The other thing is that logrotate is normally running as user root, and the root user might be why manually running logrotate would ask about trusting, but if this is running as part of the system and has that issue, then I’m not sure about the cause.

When you run the app as a regular user the log would be owned by that user. When running the app as root (with sudo) the log would be owned by root. One would need to be root in order to write to “/var/log”, but if you were to build a custom location, e.g., something like “~/logtest”, then even a regular user could log there. However, if logrotate is running as root, then the actual log file would be owned by root (not necessarily a bad thing since this can be worked around).

If you use “ls -l ~/Desktop/*”, is everything owned by your regular user? What permissions does your icon and any log file have?

after further testing and investigations Im not sure log rotate is going to work sadly. Deepstream continues to write to the logged file rather than change to a new one, the new log files are created as 0bytes.
I tried “copytruncate” but when it does that it switches to the new file but at the full maximum size.

Regarding the new problem I’ve checked all ownership and permissions and all are correct. I think it something much worse than that sadly

I tried installing gnome-tweaks (not to fix these problems, just for a look) but when I did this I got the error message
Shell not running or DBus service not available

should these be running? can I restart them?

thanks

I would have to sit down and look at the actual “~/Desktop/*” content to have any chance of knowing what might have changed, but I can make some comments on D-Bus

D-Bus is a form of data sharing (think of clipboards used in copy and paste, but also useful for most other inter-application communications). This is originally from GNOME, and has a lot of security associated with it. In the past I’ve had many occurrences of something where D-Bus failed or refused on security grounds, so I am unsurprised any time D-Bus is involved in failures. Quite possibly this could be related to desktop icons as well if D-Bus is involved in reading them or display them. D-Bus “not running” might just be for this one application, and I am unsure of how to debug this (which is why I’d probably have to be sitting at the terminal experimenting).

The actual content output is not particularly important, but are you able to dump your gconf database with this (I just want to know if it can read the database without error):
dconf dump /
(if you don’t have this application you can “sudo apt-get install dconf-cli”)

Are your desktop icons now showing up correctly? Earlier you mentioned the icons changing while experimenting with logrotate. Is everything else basically working correctly?

I am going to suggest that in case things don’t work out well you clone the AGX now and save a copy of the rootfs (along with your application) if you want to guarantee saving what is there now if you end up flashing again.

I think in the end this will be about writing a custom log script.

thanks, I think I’ll have to go the reflashing route simply because I think it will actually work out faster than trying to find the problem.

Hopefully it doesn’t happen again!

thanks again for all your help!