I want to use the ARM DDT to profile my program (It has used MPI and CUDA) on HPC system. The super computer that I am using is PBS and for submitting the jobs I have to use the bash shells and run the command:
qsub job.sh
but I don't know how to submit the job by arm DDT application. I was wondering If you could advise me.
The easiest (as in, least invasive) way to work with a queue is to use DDT's "reverse connect".
Firstly - load the GUI on your desktop/laptop (you don't need a licence to install this). Then, add a "remote connection" in the GUI - telling DDT where to find your supercomputer - tell it the hostname, and installation path to the tools. Test, then connect.
On your supercomputer, login to a terminal... and where you previously might have a line like this in your qsub script:
./a.out
or like this:
mpirun -np 4 ./a.out
replace it with
{path-to-ddt}/bin/ddt --connect ./a.out
or
{path-to-ddt}/bin/ddt --connect mpirun -np 4 ./a.out
Now, submit your job as usual - and a dialog will appear on your GUI on your laptop. Click accept, you're now debugging.
Related
I'm writing script to run iperf on linux device accessible via adb.
From a terminal, when I run the command: adb shell iperf -c ......
I get the log of the command 50 s after the command starting.
inconvenient: during 50 s you are not sure that iperf has started
I tried the logcat command (logcat --pid ...), It gives the same result.
From a terminal, when I enter adb session first and then I run the command: iperf -c .....
I get the log of the command in real time.
inconvenient: I'm not able to automate the procedure, because I have to start the adb session first
For the first use case: Is there a way to force "log flush" in order to get the log in real time?
For the second use case: Is there a way to send commands to already opened adb shell session?
Is there any other ways to launch iperf on device and get the log in real time?
The solution i found is the library pexpect that allow to interact with adb session.
I have a program running on armbian single board computer. The program starts with -b option during the startup of the system. I created this simple shell script
#!/bin/bash
#Myprog server start
sudo -b /home/myprog/myprog
This program is C written and it sometimes outputs some information with printf functions. But since it is started with -b option there's is noting in the console.
Now when I log in to the armbian via ssh with Putty I want to occasionally read the output of this program. Is it even possible?
Not exactly what you’re asking, but generally speaking it’s better practice to redirect output to a log file than to try to interactively look at the console output for a background app.
Something like:
sudo -b /home/prog/myprog >> /home/prog/log.txt 2>&1
Should do it.
Then view output with
tail -f /home/prog/log.txt
If it’s really important to you to run interactively without logs, I would suggest running it from within “screen” without backgrounding it.
screen
sudo /home/prog/myprog
Then ctrl-d to detach and let it run in background. screen -r to reattach.
I'm using a psuedo terminal, /bin/sh -i, by calling normal commands for posix_openpty() then fork(), in language C.
When I run from command line GUI terminal like this
$ ./MyTerminal
or
$ sudo ./MyTerminal
or as root like this
# ./MyTerminal
all works very good and as expected, no problems.
However, when I make a systemd service file like this, it works fine
[Service]
User=root
But when I try to get systemd to run it as normal user like this
[Service]
User=debian
THe first output for /bin/sh -i is
/bin/sh: 0: can't access tty; job control turned off $
And the terminal does not really work.
When I run /bin/bash, fork() w/posix_openpty() is returns me this, but the terminal generally works ok
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
Is such a weird prolem because when running outside of systemd everything works perfect. I see this problem in 1 other question but no clear solution. So what I have to change to make systemd run my file perfectly? Thanks for your help.
I have compiled a c program into an executable that I would now like to integrate into the applications menu in Debian 7.4 XFCE. In order to run the application under normal circumstances, I am required to type
sudo myprogram
Now I have created my .desktop file and placed it in /usr/share/applications
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=myprogram
Comment=configuration loader
Exec=sudo loader
Icon=/usr/share/icons/hicolor/48x48/apps/myprogram.png
Terminal=false
Categories=Development;IDE
The item is added to my applications menu as expected, and the icon shows up properly. The problem, however, is that double clicking the menu item to launch the application does nothing.
If I navigate to /usr/bin (where I have placed my executable) and type "sudo myprogram", the program launches as expected.
What can I do to fix this issue and get the program to launch from the menu? Perhaps /usr/bin is not the correct place to put it, or I have the incorrect Exec command. I greatly appreciate the help.
I ended up using (after installing gksu)
Exec = gksu myprogram
this launches a graphical sudo prompt, which is sufficient for my needs.
This is what the setuid bit in the permissions is for. It makes executables run with permissions of the file owner. This only works on actual executables, not on shell scripts!
sudo chmod u+s myprogram
sudo chown root myprogram
./myprogram # now runs as root
Please be careful when using this as it will always execute that program as root no matter who executes it. You can limit access by setting it to your usergroup and deny all execute.
chgrp "${USER}" myprogram # provided you have individual groups set up
chmod a-x myprogram # deny all execute
This approach does not need additional installation of packages.
Terminal=true opens a new terminal window which runs
sudo -i to ask for the password.
Then, using sh to run the program, the Terminal is closed and myprogram runs in the background because it has a & at the end.
[Desktop Entry]
Type=Application
Name=...
Exec=sudo -i sh -c "myprogram &"
Terminal=true
Request: Please report if it works under your OS.
Tested under:
Xubuntu
The pkexec solution from askubuntu:
Exec=pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY APP_COMMAND
Try adding this to .desktop
Path=/path/to/myprogram
I'm programming application using libpcap. when I debug the application in normal mode, pcap cannot get the network device. it seems that I have to debug the application in root.
How can I debug the application in root? I have the root password.
I think eclipse has such an option that can add root for the debugging application,but I don't know how to do it.
please help.
Enable your user to run gdb as root without being asked for any
password:
sudo visudo
Add the following line after all other rules:
<youruser> ALL=(root) NOPASSWD:/usr/bin/gdb
Create or modify a debug configuration in eclipse to run gdb as root
e.g. in Run > Debug Configurations > C/C++ Application > YourProject Debug:
change Debugger > Main > GDB debugger from gdb to sudo -u <youruser> gdb
Update (and warning!):
In his comment nategoose pointed out that this answer should come with a warning:
Enabling a user to use sudo for gdb like suggested in my answer in fact gives admin privileges to him/her which in many cases might be an undesired side effect. I therefore consider the answer appropriate in an environment where it's not assumed that the user would try to harm the system (e.g. it's your own personal computer or a virtual machine)
For a multi-(non-trusted)-user environment I think it might be a better idead to utilize unix' file capabilities to enable gdb to debug an application without the need of admin privileges
You can use gdbserver on localhost to attach a existing process, the following is the command line:
sudo gdbserver :<listening port> --attach <pid>
Or you can create a new process using gdbserver:
sudo gdbserver :<listening port> <process executable>
Then you can create a debugging configuration in Eclipse, in the debugger tab, the debugger item, select gdbserver, and input the listening port in the connection tab in the bellow.
Launch Eclipse with sudo (just for completeness: http://www.eclipse.org/forums/index.php?t=msg&goto=516838&)
Update: Follow xmoex solution. If you run Eclipse as root (ie. using sudo) your files will be root-owned... which you probably don't want.
Another solution is to grant you (or the gdb executable) the rights to make some pcap captures as mentioned here. With something like this :
setcap cap_net_raw,cap_net_admin=eip /usr/bin/gdb
you should be able to allow to capture packets to gdb without being root.
Here's how I did it:
Create a C/C++ Remote Application
On the target, make sure your sudo does not prompt for a PW
Look at Debug Configurations → Debugger → Port number
Edit Debug Configurations → Main → Commands to execute before application
Change to:
sudo gdbserver :<port number> <path to application>;exit #
This will basically run the gdbserver that would normally be executed by eclipse inside the sudo, the trailing '#' will keep the eclipse command from executing.
this question was asked a long time ago but if this will help to anybody I open a bug in bugzilla and this short thread solved the problem:
bugzilla bug
From the console in the directory with your executable:
sudo gdb ./my_program
If eclipse supports remote debugging then you could do that even though it is running locally.
From the console:
sudo gdbserver localhost:<port_number> ./my_program
And then tell Eclipse the address (localhost and the port number you chose).
Oh yeah, you said the reason you were doing this was because you were using libpcap, so you may not want to use remote debugging over TCP because you may end up capturing your debugging connection packets in addition to your other network traffic.
In that case you do your remote (but really local) debugging over a serial port. I have never done this on a local machine, but you could use two actual serial ports (attaching them though a null modem) or try using a psudoterminal:
sudo gdbserver /dev/ptmx ./my_program
This will create the psudo-terminal under /dev/pts/ but you'll have to figure out the name of it, and it might also create it with restrictive permissions. You can get around those. Unless you are running lots of terminal windows as root, it is not likely that you have many entries under /dev/pts that belong to root, so take note of the one that does after running the above command and then sudo chmod or sudo chown it to make it usable for your normal user and then tell your debugger to use that as your serial connection to your remote debugging target.
easiest way, try sudo ./eclipse, then debug as usual