-1

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?

Improve this question
6
  • What is that package and where did you got it from? On which distribution Commented Sep 19, 2018 at 18:48
  • 1
    Your binary doesn't hang Linux. It hangs. No need to repeat tags in the title. Commented Sep 19, 2018 at 18:48
  • 1
    @n.m. "binary" has long been a misnomer for "executable". /dev/random is also binary. Commented Sep 19, 2018 at 18:51
  • 1
    It is an XY problem. Please explain what actual package you have installed, and you could get a lot more help. Commented Sep 19, 2018 at 20:18
  • 1
    No, the answer can only be package specific, if you want a reliable one. Those that you've got won't help you much. BTW, some rare (even benign) software are very difficult to strace reliably (e.g. setuid programs). Commented Sep 19, 2018 at 20:21

2 Answers 2

Reset to default
4

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Great. Notice that strace is not for debugging packaged binaries, but to understand the system calls done by running any executables (including those that are not packaged)
Also, strace don't work well on setuid executables
1

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

Improve this answer

3 Comments

I'm curious what you expect to find in the documentation that would be helpful in this investigation. Or are you just suggesting using the documentation instead of using the --help option?
I'm not sure "your command isn't doing anything? it might be malware!" is accurate or useful advice
We don't know the source of the package. Some people might setup e.g. a .deb source somewhere (for Debian or Ubuntu) and publish malicious software thru that. It is unlikely, but not impossible. And trusting a .deb package provider is a social issue, not a technical one

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.