I'm trying to decrease a Linux image running SuSE, and thought about running strip on all of the system's executables. Even though I may not re-gain much disk space this way, would there be any harm in doing so?

  • 2
    Are you sure they're not already stripped? Run file and see if it reports stripped in the output. – Stephen Harris Aug 1 '16 at 20:32
  • @StephenHarris true, most of them are, but there are some other packages i've installed manually that aren't, so I'm interested in any side-effects of running a system-wide strip – Délisson Junio Aug 1 '16 at 20:39
  • 2
    If you run find / -type f -exec file {} \; | grep 'not stripped' you should get a list of all not stripped binaries, which should turn to be a rather short list. Then you only need to run strip on that. It probably is quicker that well too. – grochmal Aug 1 '16 at 21:10

It's not the case for Linux (just checked...), but on other systems (such as BSDs, e.g., OSX) doing this will remove any setuid/setgid permissions as a side-effect. Also (still looking at OSX), the ownership of the file may change (to the user doing the writing).

For Linux, I recall that early on, stripping a shared library would prevent linking to it. That is not a problem now, though as the Program Library HOWTO notes, it will make debuggers not useful. It prevents linking to static libraries.

Further reading:

  • Nice link. The text says to avoid stripping the kernel itself, but doesn't state why. What could be the problem with that? – Délisson Junio Aug 1 '16 at 23:13
  • The context is "need to debug" (when systems were built by linking object files for a kernel). – Thomas Dickey Aug 1 '16 at 23:28
  • +1 Excellent tip about the shared library. I knew there was at least some problem invalidating binaries, but could not remember which one. – Rui F Ribeiro Aug 2 '16 at 1:52
  • Also, programs written in the Go programming language will no longer work. The Go runtime uses debugging information to implement things like reflection etc. Don't think you're using anything written in Go? If you use Docker (which is getting REALLY popular these days) then most of the Docker commands and utilities are written in Go. – slebetman Aug 2 '16 at 6:32

Most distributions, including OpenSUSE, strip executables as part of their build scripts. You don't need to strip on the system's executables because it's already been done.

There are binaries that must not be stripped. Package maintainers take care to use correct build options to avoid stripping them. This includes binaries that load libraries dynamically in unusual ways, doing some self-introspection rather than normal startup-time loading or a plain dlopen. This also includes many executables that consist of bytecode plus a bytecode interpreter for which strip mistakes the bytecode for debugging data.

A side note: if you want to save space, OpenSUSE is not the right distribution for you. OpenSUSE has very coarse package granularity. For a smaller system, use a distribution with finer package granularity so that you can install only the parts you need. In the desktop/server range, Debian and Arch are good choices. You may also consider distributions that target embedded systems such as WRT.

  • In this case, I'm stuck with SuSE (The commercial distribution) and trying to save space, not the other way around. But I inspected the system binaries and saw mostly stripped files, indeed. – Délisson Junio Aug 2 '16 at 0:19
  • Some ~20 years ago I used to run SuSE on a dual Pentium II machine, with 64 MB RAM (that's MB, not GB), and two SCSI disks of 300 MB. That machine had 120 users, with maybe 10 logged in simultaneously at any given time from DEC X terminals. The machine was doing mostly DNS, mail, web serving, and web browsing (with Netscape). Things have changed in the Linux land since those days. – Satō Katsura Aug 2 '16 at 5:47

If you're running a distribution that installs binary packages from repositories (most distributions, including SUSE, do this), then any changes you make to executables will be overwritten the next time you update (or reinstall) the package that contains them.

Additionally, they'll be reported as having the wrong checksum and size (and date, if you didn't run strip with the --preserve-dates option) whenever you verify installed packages. You could make the rpm match up with your changes by rebuilding the package from the installed files.

If you want to strip binaries for installation, you may be better off building those packages from source and adjusting the compiler/linker flags. The package should be built using the distribution's own tools for that task (such as rpmbuild, dpkg-buildpackage, or makepkg). For people who need to do this kind of customization extensively, there are source-based distributions and even Linux From Scratch. However, building from source takes much longer, as well as using more disk space than you eventually save with the smaller binaries.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.