This question already has answers here:
How should strace be used?
(12 answers)
Closed 4 years ago.
I installed a package on my linux machine. When I run the installed binary, it hangs:
$installedBinary --help
is supposed to return a list of command line options. Instead, the program hangs and doesn't respond. It closes when I run control+c.
How can I investigate this problem?
Start with strace -ffo traces ./installedBinary --help. And then inspect traces.* log files, in particular the last lines where it may show what it is blocked on. See strace(1)
You can also do that from htop. Locate the blocked thread and press s for strace and l for lsof.
Maxim Egorushkin's answer is a good one. But on Linux, most programs have some documentation (often, at least a man page, see man(1) & man(7)), and most programs are free software. And the documentation should tell a lot more than --help does (the output of --help is a short summary of the documentation; for example sed(1) explains a lot more than sed --help). Maybe the behavior of your program is explained in the documentation (e.g. depends upon some environment variable).
So you should also read the documentation of your installedBinary and you probably could get its source code, study and recompile it. If you have the source code and have built it, you usually could compile it with DWARF debug information (e.g. adding -g to some CFLAGS in a Makefile...) and run it under gdb
Notice that even on Linux you might have malware (e.g. for Debian or Ubuntu you might have found a .deb source which is used to publish malware; this is unlikely, but not impossible). Trusting a binary package provider is a social issue, not a technical one. Your installedBinary might (in principle) be bad enough to put you in trouble. But it is probably some executable.
Perhaps your installedBinary is always waiting for some input from its stdin (such a behavior might be unusual but is not forbidden) or from some other source. Then you might try installedBinary < /dev/null and even installedBinary --help < /dev/null
Related
I have the same problem of #Hias about this topic:
https://unix.stackexchange.com/questions/420978
The more interesting answer is:
"modify bluetooth kernel module, set any discoveryFilter using Bluez (i.e.: RSSI -127)."
The answer is not clear to me.
Where is the "bluetooth kernel module"?
That is, what is the directory?
In the output of this command:
sudo btmgmt --index 1 find
Between "hci1 type 7 discovering on" and "hci1 type 7 discovering off" there is a time of 11 seconds (I counted in mind).
How to change this time?
If --timer parameter is 5 for example, i must wait other six second to execute the command, otherwise it gives me the output of busy: 5+6=11
For business needs I need to extend the scan times through the btmgmt command (or its configuration file, if it exists) and not through similar commands, the watch command is too draining on the raspberrypi and does not respond to my goals.
The answer is not clear to me.
Where is the "bluetooth kernel module"?
That is, what is the directory?
You probably don't want to modify the kernel module. Unless you know C very well and have built kernel modules before, I would advise against it. Plus, modifying the kernel module would leave your program in an unusable state on anyone's computer unless they also patched their kernel the same way you did. That said, if you absolutely positively think that's the way to go, I'm assuming you're on raspbian, you ought to be able to just apt install linux-sources and then you'd go to the /usr/src/ directory and unpack the kernel from the tar archive found there. Then once you're finished editing the kernel you could compile a new kernel. Have a look over at the gentoo docs or linux-from-scratch pages for quick and easy ways to compile a kernel or a kernel module. Again, I would completely scrap the idea of messing with the kernel, but that's me.
For what you want to do with btmgmt, there is a Python wrapper for btmgmt which would give you fine grain control over how you use that specific tool. With Python at your disposal, even if the btmgmt tool doesn't offer a specific feature that you are looking for, or you can't figure out how a specific feature works with it, you could build that in to your script yourself.
I have been reading linux kernel dev by Love (3 edit). I assume, it is quit well known book for kernel development. I have although encounter, I am not able to use code, because I do not know how to compiled in kernel space (e.g. cannot use <asm/thread_info.h>). So i have decided to read guide to compile and use kernel modules first (I have also disable secure BIOS in order to load my own modules), here How Do Modules Get Into Kernel. I suppose, once I would learn, how to compile kernel space, then would be able to use kernel libraries, thus examples of the book.
Then, from exactly that link (guide), there is mentioned:
It is highly recommended that you type in, compile and load all the examples this guide discusses. It's also highly recommended you do this from a console.
You should not be working on this stuff in X.
Modules can't print to the screen like printf() can, but they can log information and warnings, which ends up being printed on your screen, but only on a console.
If you insmod a module from an xterm, the information and warnings will be logged, but only to your log files.
You won't see it unless you look through your log files. To have immediate access to this information, do all your work from console.
But how can I use console? If i do echo $TERM, : xterm-256color. So i do have xterm, but I should not have.
Conclusion: There are 2 questions.
Should I learn the guide of kernel modules first, in order to use Love's examples?
If so, How do I use console instead of xterm then?
So I'm making a better command-line frontend for APT and I'm putting on some finishing touches and when the code below runs.
Command::new("unbuffer")
.arg("apt")
.arg("list")
.arg("|")
.arg("less")
.arg("-r")
.status()
.expect("Something went wrong.");
it spits out:
E: Command line option 'r' [from -r] is not understood in combination with the other options.
but when I just run unbuffer apt list | less -r manually in my terminal it works perfectly. How do I get it to run properly when calling it in Rust?
Spawning a process via Command uses the system's native functionality to create a process. This is a low level feature and has little to do with your shell/terminal that you are used to. In particular, your shell (e.g. bash or zsh, running inside of your terminal) offers a lot more features. For example, piping via | is such a feature. Command does not support these features as the low level system's API doesn't.
Luckily, the low level interface offers other means of achieving a lot of stuff. Piping for example is mostly just redirecting the standard inputs and outputs. You can do that with Command::{stdin, stdout, sterr}. Please see this part of the documentation for more information.
There are a few very similar questions, which are not similar enough to warrent closing this as a dupe though:
Execute a shell command
Why does the compgen command work in the Linux terminal but not with process::Command?: mentions shell built-in commands that do not work with Command.
Executing find using std::process::Command on cygwin does not work
Edit: The actual problem is with the method by which the binary is updated and isn't due to an issue with gdb. Please see the answer below for details.
Original question:
Somewhat recently, I can no longer compile a program while gdb is running the program and stopped at a breakpoint. Trying to write to the binary again will result in a "text file busy" error.
This is on Ubuntu 16.04 LTS 64-bit, kernel 4.4.0-75.
I don't think I'm looking for the right thing, as a few searches for "gdb text file busy" or similar isn't yielding any results. The gdb manual specifically mentions this behavior (compile again while running gdb) is supported and indeed I have done this many times previously.
Would appreciate any pointers on what has changed and how to prevent this from happening.
Some further searching indicates this excellent post https://unix.stackexchange.com/a/188041/10847 which explains that the method by which the binary is updated is relevant here. In this case, the build system is copying the binary using cp a b which will fail. cp -f a b will delete b, then overwrite with a, allowing gdb to continue debugging the old binary while the new one is written to disk.
I am using Windows 10.
I downloaded setup-x86_64.exe from https://cygwin.com/install.html and am selecting the defaults (Install from Internet/Direct Connection/default locations).
I have tried several mirrors including cygwin.mirror.constant.com
I am accepting all the default packages plus some basic developer stuff (gdb, make) and check "Select required packages (RECOMMENDED)".
I get quite a way through the Cygwin Setup and then get the first of many pop-up messages "IO Error Opening file....._autorebase/binutils/cygwin/grep/mintty etc. Do you want to skip this package?"
If I skip the packages, I get a non-working Cygwin install (it can't find mintty). If I don't skip the packages, it hangs when the Cygwin installer hangs when it gets to the first of the problem packages.
Thanks in advance about what part of the setup process I am missing.
A bit late, but anyway: I have stumbled across the same problems yesterday when I tried to install Cygwin on Windows 10 the first time.
I have followed all advice given at various sites (including this one): Disabled antivirus software, followed the Cygwin FAQ, and so on, but to no avail.
Then I studied the setup log and found a line which told something about an address mismatch (sorry that I don't have the exact wording - I surely won't repeat the experiment ...). That lead me to the idea that it might something have to do with ASLR (a technique for hardening the system against malware).
The next step was to turn off ASLR via the UI of Windows Defender. After I had done that, I could install Cygwin without any problems. I have not yet tested if I actually could use Cygwin when I turn on ASLR again; I don't feel very comfortable when having turned it off completely.
The alternative would be to turn off ASLR per executable. This is also possible in Windows Defender's UI. But it could mean adding dozens of exceptions, depending on how many Cygwin packages you have installed.
The technical reason for the problem is how POSIX's fork() works. Basically, it clones the parent process's image, using the same offset addresses. But when ASLR is active, those offsets will change when cloning the process, which will make fork() fail. Since fork() is extensively used by Cygwin, it can't operate as intended when ASLR is active.