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
Is there anything similiar to Linux's "screen"? What I want to do is launch console application created in Java. Then let's say I want to execute command to the running application. For example I want to tell it to exit so I'll tell it command 'exit'. On Linux I can open the application "in screen" and later if I want to tell it any command I can attach the "screen", tell it the command and detach. I don't need screen but I need something that can do this. It would also be cool if I could do it without installing any additional software.
You can install cygwin and within cygwin install screen.
Here is the situation, I'm planning to use a simple script to start a program call "STAF", when the Suse system is fully booted. I have achieved this by putting it in the "/etc/init.d/", but this script is basically executed at the background, which means that I cannot see its progress.
When the "STAF" is started this way it works but it doesn't show any working progress when its running service (for example ping, or system backup), instead if I start the "STAF" manually by running the same script whit a terminal, the working progress of "STAF" can be seen on the terminal. Its sort of like the program needs to be started with a interactive terminal, but how can I make this starting process automatic and it should imitate human opening a terminal and run the script?
Sorry if I explained it poorly because its a confusing situation. Thanks.
First, go to the KDE Startup and Shutdown options under System Settings. Then add this command as a new startup script:
konsole -e bash nameofyourscript.sh
I believe the screen utility can do what you describe. Instead of running STAF on startup, you would run screen STAF. To open that terminal, you would run screen -ls to get the screen ID, and screen -r ... to open it.
(Disclaimer: I have not tried this.)
I am debugging a program that makes use of libnetfilter_queue. The documentation states that a userspace queue-handling application needs the CAP_NET_ADMIN capability to function. I have done this using the setcap utility as follows:
$ sudo setcap cap_net_raw,cap_net_admin=eip ./a.out
I have verified that the capabilities are applied correctly as a) the program works and b) getcap returns the following output:
$ getcap ./a.out
./a.out = cap_net_admin,cap_net_raw+eip
However, when I attempt to debug this program using gdb (e.g. $ gdb ./a.out) from the command line, it fails on account of not having the correct permissions set. The debugging functionality of gdb works perfectly otherwise and debugs as per normal.
I have even attempted to apply these capabilities to the gdb binary itself to no avail. I did this as it seemed (as documented by the manpages that the "i" flag might allowed the debugee to inherit the capability from the debugger.
Is there something trivial I am missing or can this really not be done?
I run into same problem and at beginning I thought the same as above that maybe gdb is ignoring the executable's capability due to security reason. However, reading source code and even using eclipse debugging gdb itself when it is debugging my ext2fs-prog which opens /dev/sda1, I realize that:
gdb is no special as any other program. (Just like it is in the matrix, even the agents themselves they obey the same physical law, gravity etc, except that they are all door-keepers.)
gdb is not the parent process of debugged executable, instead it is grand father.
The true parent process of debugged executable is "shell", i.e. /bin/bash in my case.
So, the solution is very simple, apart from adding cap_net_admin,cap_net_raw+eip to gdb, you have also apply this to your shell. i.e. setcap cap_net_admin,cap_net_raw+eip /bin/bash
The reason that you have also to do this to gdb is because gdb is parent process of /bin/bash before create debugged process.
The true executable command line inside gdb is like following:
/bin/bash exec /my/executable/program/path
And this is parameter to vfork inside gdb.
For those who have the same problem, you can bypass this one by executing gdb with sudo.
A while ago I did run into the same problem. My guess is that running the debugged program with the additional capabilities is a security issue.
Your program has more privileges than the user that runs it. With a debugger a user can manipulate the execution of the program. So if the program runs under the debugger with the extra privileges then the user could use these privileges for other purposes than for which the program intended to use them. This would be a serious security hole, because the user does not have the privileges in the first place.
For those running GDB through an IDE, sudo-ing GDB (as in #Stéphane J.'s answer) may not be possible. In this case, you can run:
sudo gdbserver localhost:12345 /path/to/application
and then attach your IDE's GDB instance to that (local) GDBServer.
In the case of Eclipse CDT, this means making a new 'C/C++ Remote Application' debug configuration, then under the Debugger > Connection tab, entering TCP / localhost / 12345 (or whatever port you chose above). This lets you debug within Eclipse, whilst your application has privileged access.
I used #NickHuang's solution until, with one of system updates, it broke systemd services (too much capabilities on bash for systemd to start it or some such). Switched to leaving bash alone and instead pass a command to gdb to invoke the executable directly. The command is
set startup-with-shell off
OK, so I struggled a bit with this so I thought I'd combine answers and summarise.
The easy solution is just to sudo gdb as suggested but just be a bit careful. What you're doing here is running the debugged program as root. This may well cause it to operate differently than when you run it from the command line as a normal user. Could be a bit confusing. Not that I would EVER fall into this trap... Oopsies.
This will be fine if you're running the debugged program as root with sudo OR if the debugged program has the setuid bit set. But if the debugged program is running with POSIX capabilities (setcap / getcap) then you need to mirror these more granular permissions in bash and gdb as Nick Huang suggested rather than just brute forcing permissions with 'sudo'.
Doing anything else may lead you to a bad place of extreme learning.