I want to run a program when my embedded Linux's desktop has started up, in the same way as Windows runs programs in the "Startup" folder. How can I do this?
Specifically, my target hardware is Beaglebone Black, the Debian variant (rev C board). The Window Manager is the default one.
In Linux these are called init scripts and usually sit in /etc/init.d. How they should be defined varies between different distros but today many use the Linux Standard Base (LSB) Init Script format.
Good readings on this:
https://wiki.debian.org/LSBInitScripts
https://www.debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian
There are multiple ways to start a program, it turns out. LXDE - the window manager - supports auto-start of .desktop files places in either ~/.config/autostart or /etc/xdg/autostart - hooray!
http://wiki.lxde.org/en/Autostart
Except... though I can run a simple program as proof-of-concept in this way, when I try to run mine, it fails. I can't figure out why. The file
.xsession-errors.old
contains X server errors ("resource temporarily unavailable").
I am now using another mechanism - running the code from a shell script (this is necessary because I need to specify a working directory for the program). This uses the "autostart" file in /etc/xdg/lxsession/, and at least it works. Well kind of. I either have to "sleep 5" before running, or prefixing the run with an # symbol which forces a retry if it fails. It looks a little like something my code is dependent on is not in place at the precise time the autostart mechanism finds it. I can find no way of ensuring startup order. This is plainly a crock of stinky stuff.
Related
Good day everyone,
I am working on a project that requires me to have 7+ programs (no GUI, runs on shell) open, all interacting with each other. For example, Program 1 asks a question to Program 2, and it uses Program 3 and 4 to solve that etc.
So what I do is, I open many terminals and run each one on a different terminal, then I place them on my screen and go ahead. But this is a troublesome process, as every time I need to recompile I need to run them all one by one again, even worse, if I ever turn my computer off, I need to open many shells, go to the directories, run them all so and so.
What I want is a file that would open the necessary terminal windows for me and go to the correct directory on each, then run the programs. I don't know much about shell-scripts, but I assumed this must have been possible. Can you give me any directions? Note that the programs should not run in background or in different tabs. I need to be constantly observing the displays.
I have read this post about a similar issue but that does not work for me, because I need them on different terminals.
Thank you.
We suppose you are using gnome terminale, so the command would be:
gnome-terminal --working-directory "{{APP_FOLDER}}" --command "{{APP_EXCUTABLE}}"
That approach can be traslated to any other terminal emulator.
I'm trying to achieve this on a Raspberry Pi 4:
Less then 10 seconds boot time
Custom UI ( build with python/Gtk for example )
I already tried editing the /boot/config.txt with
# Disable the rainbow splash screen
disable_splash=1
# Disable bluetooth
dtoverlay=pi3-disable-bt
#Disable Wifi
dtoverlay=pi3-disable-wifi
dtoverlay=sdtweak,overclock_50=100
# Set the bootloader delay to 0 seconds. The default is 1s if not specified.
boot_delay=0
# Overclock the raspberry pi. This voids its warranty. Make sure you have a good power supply.
force_turbo=1
Also I have an A2 class 10 SdCard and I have disabled almost every service that I don't need.
My best results are 14 seconds boot time until my app started, but I need to make it faster....
I would like to achieve something like this in terms of speed, but using GTK, not QT:
https://www.youtube.com/watch?v=TTcP3xeLrEY
I am also currently trying to reach fast boot time with my Raspberry Pi 4, but I cannot breach the wall of 10s without radical solutions such as buildroot or unikernel.
What do you need on your system ? On Raspbian you can use those two commands to verify what is slowing down the boot process :
systemd-analyze critical-chain
and
systemd-analyze blame
Critical chain will show in red the services blocking the boot.
On my setup I could desactivate all those services :
hciuart #GPIOs
nmbd
smbd
wpa_supplicant
systemd-timesyncd
rpi-eeprom-update.service
raspi-config.service
networking
Just use sudo systemctl disable SERVICE , I guess there are others that are not critical for your application.
Also, in the cmdline.txt file in /boot you can add quiet fastboot , it will decrease boot time further
GTK is a toolkit coded in C and callable from C code.
In practice, Python can be 10x slower than equivalent C code.
Did you consider starting Xorg with a minimal window manager and a single client coded in C? Without a single line of Python? Of course, read more about X windows systems protocols and architecture then about EWMH.
So, remove the Python interpreter on your RaspBerryPi (probably /usr/bin/python) and replace every old Python script by an equivalent ELF executable coded in C or in C++ and compiled with optimizations (so gcc -O3 with GCC). See also linuxfromscratch.org for inspiration and guidance.
I would like to achieve something like this in terms of speed, but using GTK
Of course, you want to use a GCC cross-compiler.
If that still does not work (after weeks of effort), replace your hardware by something more powerful.
It would be easier for you to install a Linux distribution such as Debian on your development laptop or desktop. Because most of what you would learn on your development computer (e.g. Advanced Linux Programming) can be applied to the RaspBerrry Pi. And cross-building on a Debian laptop for a Raspbian RaspBerryPi is really easy. Focus on learning low-level things starting from their C code. E.g. code your GUI directly with Xlib (no GTK, no Qt) in C. The same C code is very likely to be easily portable -if you write it carefully- from x86/Debian to your Raspberry Pi.
You could read the From powerup to to bash prompt howto; most of that document is relevant for a RaspBerryPi running RaspBian.
You could even avoid starting any Xorg or other display server (e.g. WayLand) on your RaspBerryPi. That certainly would make it boot faster.
You could replace your /sbin/init program by your own one coded in C entirely. That process starts within less than a second, and forks all other processes. Your custom GUI could be just Xorg with your single X11 client coded in C.
Observe that you could have the source code (millions of source lines) of all the code running on RaspBian. Then download it, study it, and optimize it. Of course this could take decades.
First, this is a poorly formed question. You've provided no details on what your boot process is or what OS/configuration you're running with for people to help.
Regardless, you appear primarily focused on a short boot time. So since your question is generic... here is a generic answer: there is nothing magical about the boot process. There is no config file with a fast_boot=1 option that gets you up in 0 seconds instead of 15. You want to boot faster? Do less.
Throw out slow crap like Python
Remove unnecessary application loading from your init system (sysvinit/systemd/whatever)
Remove unnecessary driver loading from the kernel startup. Start by trimming down your device tree to only the hardware you really need to initialize.
Optimize your bootloader (u-boot?) to only initialize the hardware you really need (obviously turn off any prompt and timer it may implement)
That's how you boot faster.
i'm running raspbian (2015-05-05-raspbian-wheezy.img) in qemu using compiled kernel (https://github.com/dhruvvyas90/qemu-rpi-kernel) on ubuntu 14.04. my final goal is to launch my python script within the emulation.
i'm following manual from http://www.unixmen.com/emulating-raspbian-using-qemu/, though many others suggest very similar sequence of actions.
things i'm trying and issues i'm experiencing:
first boot is more or less ok. i comment the line in /etc/ld.so.preload as suggested and reboot.
on second boot (after i remove init=/bin/bash) and all subsequent boots i get
ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open moddep file '/lib/modules/3.10.25/modules.dep.bin'
some googling suggested to run "sudo rpi-update". it didn't help, same message during boot.
on second boot (after i remove init=/bin/bash) and all subsequent boots i get
fsck died with exit status 6
looking into "/var/log/fsck/checkfs" as suggested tells that some location is not there, but it doesn't say which one
running "startx" produces error message from 1. it loads the UI eventually, but desktop only has "wastebasket" icon. there is also a thick white stripe on top of the screen blinking, like it keeps trying to load a tab but fails everytime. qemu window stops to respond to further interaction after this.
running "sudo apt-get upgrade" installs some packages, but after reboot i can't even get to UI - just blank screen with mouse cursor.
i'm not very experienced with how linux is configured at low level. i understand that i might be doing something completely stoopid.
so, my questions are:
how do i debug? i couldn't figure out the settings for qemu to write logs. i really don't want to fallback to gdb, as i'm not debugging qemu itself, just want to get notification on it's events.
ctrl key doesn't seem to work inside qemu window.
no copy-paste available. or i can't see how to turn it on.
am i missing something? from all the manuals i have seen it seems like this should go much much smoother. like it should "just work".
Since your post many things changed. The most important things is that now using Andrew Baumann GitHub repo you can build QEMU that boots recent Raspbian. I described my experience woth this code here. Instructions are straight forward. Implementation needs polishing but it best compilation of work so far.
To answer your questions:
QEMU have -s and -S options for GDB. First option setup gdb server hook and second freez CPU, so you can connect debugger. This is not for QEMU debugging this for guest system debugging. Default QEMU logging is to stderr, so if something valuable happen you will see it in terminal. You can raise QEMU verbosity by uncommenting various *DEBUG_ statements in source code. Also check help for -d and -D command line flags of QEMU.
Not sure I can help with this. Only thing that I can say is that my QEMU version 2.5.50 reacts to Ctrl+Alt which exits from GUI after capturing cursor, so it looks like QEMU understand Ctrl key. I assume that QEMU do not capture your special keys combination because your window manager do it before passing to QEMU.
This also not work for me, but I see some work was done in this area. Not sure how to enable and use that feature.
Emulating any hardware is very complex and requires a lot of work. All emulated targets are limited to some most important features. BCM2835/BCM2836 (Raspberry Pi/Raspberry Pi 2) SoC are still not accepted by mainline QEMU, so just work will not apply to those platforms.
I am working on a Linux machine (running openSUSE 13.1 w/ KDE, specifically) and I would like to determine what commands are actually being issued in the background when I do something with an application's GUI.
My question is very similar to the following one which has received no answer:
https://stackoverflow.com/questions/20930239/how-can-i-see-the-commands-being-passed-in-backend-of-a-gui-application
If it helps at all, the specific task I am trying to accomplish is figuring out what the command line-equivalent is for sending a file to the Trash in KDE's Dolphin utility. I would like to make an alias for this functionality in my .bashrc so that I have a "gentler" alternative to rm. But I would rather know the answer to my more general question so that I can do similar things in the future.
My naive guess was that a log file might exist somewhere. Then I could do a task with a GUI and just tail that log file afterward to see what the underlying commands were for what I just did in the GUI. As far as I can tell, however, no such log exists.
To move a file foo to your trash bin, try
mv foo $HOME/Trash/
so you could make that a shell function in your .bashrc
function movetotrash() {
mv $* $HOME/Trash/
}
AFAIK, most GUI applications don't have log files. They are generally free software (and using free software libraries), so you could study their source code and improve it. Try to interact with their communities (and use strace as I commented)
BTW, not every GUI application is using commands. Some are (e.g. IDE are indeed forking commands like gcc) but others just do directly syscalls (probably a file manager won't fork an mv but just would copy contents or call the rename(2) syscall).
I am curious if it is possible artificially modify the server load in Ubuntu or more generally linux. I am working on an application that reacts to the server load, and in order to test it it would be nice if I could change the server load easily.
I am currently running an over-active program that will literally generate load, but I'd prefer to not continue overheating my laptop (it's getting hot!).
One of the most important things to know about Linux (or Unix) systems is, everything is just a file. Since you are just reading from /proc/loadavg, the easiest was for you to accomplish what you are after is simply make a text file that contains a line of text that you would see when running cat /proc/loadavg. Then have your program read from that file you created instead of /proc/loadavg and it will be none the wiser. If you want to test under different "artificial" situations, just change the text in this file and save. When your testing is done, simply change your program back to reading from /proc/loadavg and you can be sure it will work as expected.
Note, you can make this text file anywhere you want...in your home directory, in the program directory, wherever. However, you shouldn't make it in /proc. That directory is reserved for system objects.
You can use the stress command, see http://weather.ou.edu/~apw/projects/stress/
A tool to impose load on and stress test a computer system
sudo apt-get install stress
To avoid CPU warm, you can install a virtual machine with small cpu capacity. virtualbox and qemu-kvm are free.
Use chroot to run the various pieces of software you're testing with a specified directory as the root directory. Set up a manufactured/modified /proc/loadavg relative to that new root directory, too.
chroot will let you create a dummy file that appears to have /proc/loadavg as its path, so the software will observe your manufactured values even if you can't change your code to look for load data in a different location.
Since you don't want to actually/literally stress the machine, something like stress is not what you are after.
As stated, /proc/loadavg would be the place to set system load averages (faux loads).
But if that's also not the meat of what you're after, I would absolutely suggest
getloadavg
watchdog
and even possible Munin plugins
There're two methods.
Hacking /proc/loadavg
The machine is not overstressed
Your program reads load valus from a file
Todo: hack Linux to report fake load value
Modify your prg
The machine is not overstressed
Your program reads load valus from a file
Todo: change 4 characters in your prg: replace /proc/loadavg with /tmp/loadavg
You can decide now. Calculate costs ;)