In our embedded system, we have properly set udev to run a script located in /etc/udev/scripts/mount.sh. This works very well. However, we cannot successfully run an application from inside this script.
This is very weird. We tried to write this application call in a script, say test.sh. If we call test.sh from udev script (mount.sh), nothing happened. It only works if we call test.sh from the shell.
Does anyone know what's the problem here?
Updated:
test.sh looks like:
#!/bin/sh
/usr/local/app/appipc "[header]usb,add"
appipc is just a simple Qt application to use QLocalSocket to connect to a local server by name. If we run this script in shell, it works. But not from udev script (mount.sh).
Finally we figured out that, the Qt lib was not able to load correctly if we run a Qt application from udev script. That's why we doubt it never runs. If we run a regular C application, everything works well!
This is kind of silly and negligent of us! We should consider this in advance. Thanks everyone for the time.
Related
So I'm basically wanting to get a script to run on system boot. It's basically an SSH callback. I've tried a few ways that I've gotten to work in the past on other distributions, but having a little bit of difficulty here.
First thing I've tried was adding the /path/to/script.rb to /etc/rc.local. However, this file does not exist on the latest version of Kali Linux. I tried to create it and replicate my old Ubuntu rc.local file, but it didn't run on system startup.
Next thing I tried was creating an executable bash script in /etc/init.d/, following the update-rc.d script.sh defaults and making the file executable. Restarted and nothing. If I run the script manually, it works. I tried to redirect the output to a file in the tmp folder, but it doesn't appear that there are any errors from what I'm understanding.
Are there any other ways to get an auto run script started other than these two methods? Seem to be the most common way to get this working, but it's just not doing it for me.
Add script to
/etc/init.d
Run command:
chmod 755 /etc/init.d/script
Run command:
update-rc.d script enable
I am trying to run a few scripts at each boot of the raspberry pi. I have been able to verify that when they are not configured to start automatically, I can run them, and they all work exactly as intended (and in only one instance). I have tried quite a few methods of autostarting these scripts, and I have found that using a desktop entry in .config/autostart directory to be my preferred way of doing it. I have also tried editing rc.local, crontab, systemd, and entries in .config/lxsession/LXDE-pi/autostart with no more success.
The issue is that when I have the scripts running at boot, there is a duplicate of the script running (I have it set to open a new instance of LXterminal, though there are not duplicates of the terminal). The script runs at boot just fine, but I am cannot figure out why there seems to be a "ghost" version of the script too. I have the autostart commands set to write to log files that show that the scripts are running more than once. I have also tried this on a fresh raspbian install. Could someone help me figure this out? I'm at a loss on what my issue is. This is for use of Amazon Alexa.
This is what I have in /home/pi/.config/autostart/AlexaBoot.desktop:
[Desktop Entry]
Name=AlexaBoot
Exec=lxterminal -e "/bin/bash /home/pi/Desktop/alexa_boot.sh"
Type=Application
I can post what I have in the autostarted script if necessary. Thanks.
Found a fix for this. My solution is outlined on a similar Github issue, hopefully this is able to help someone with the same issue.
I try to execute a java application at startup in a yocto based linux device. I added a script at /etc/init.d/etic and made it executable. If I call at the shell /etc/init.d/etic start or /etc/init.d/etic stop the application is started an stopped as expected. Then I called on the shell update-rc.d etic defaults and the symlinks were created. According to what I found on the web, this should be enough, but somehow the application is not started. What did I miss? How could I check what is going wrong or is there any minimal example which should work which I can try to extend?
Well, often such issues are due to a different environment when executing the start script by hand, as compared to when it's being run from the init system. For instance, your .profile and .bashrc won't have been sourced, when running from the init system.
You can use eg logger to easily log things from your init-script, and this rather easily find out what goes wrong.
So I have a script that is launched on login via rc.local. The script calls a few other scripts to be launched and ran. However the console says that the file and/or directories could not be found. When I run the script manually after the login it works just fine. I have even tried to add a small delay so that I know that the system logged in. Any idea why this is and how to fix it?
Sorry if my answer is a bit vague but from what I understand is that the scripts require to be run via admin privileges. Let me elaborate, when the system starts it runs a set of specific scripts and this differs from distro to distro. Therefore, I'd check ~/.bashrc /etc/profile.dand most importantly ~/.bash_login. See what you can do there. Personally I added it here ~/.config/autostart worked fine. Don't forget to create a .desktop file.
Hope this helps
I have a custom version of CENTOS that I need to run a perl script as a daemon in at all times.
To do this I want to get it to run on startup as a daemon.
When the machine is on I can daemonize the script with the command
daemonize /var/myfolder/myscript.pl
And this works fine.
So I have an rc1 script which has a number of commands that run when the machine starts, and the very last line in it is where I try to daemonize that script. Everything else in the rc1 script runs fine, and the script doesn't output any errors, however when I check to see if the daemon is running on start up, it isn't running.
Is there another way that I can get the script to run on startup? Or any ideas on why this method doesn't work?
Proc::Daemon offers what you're looking for.
See this previously asked question: How can I run a Perl script as a system daemon in linux?
The problem was that #INC hadn't fully loaded all of the modules by the time my script was called, and so my daemon wasn't running. I used the PERL5LIB command to add the appropriate directories.
PERL5LIB='/perl:/custom/lib:/usr/local/lib64/perl5' /var/myfolder/myscript.pl &
where /perl; /custom/lib and /usr/local/lib64/perl5 are the directories which were missing from #INC