Sometimes installing some applications will start a process or service from the application being run automatically on installation. How do I install without starting them?
Asked
Active
Viewed 3.4k times
47
-
I wonder what potential there is to leave a system in an unstable state when installing kernel or DKMS packages using this kind of configuration. I don't know much about this area. – ændrük Nov 04 '11 at 19:26
-
@ændrük That has got me worried. You see I'm installing minimal Ubuntu on a drive, then instead of booting into it, I use a Live CD/USB to `chroot` and install the packages I need. Of course drivers, specifically, GPU drivers are not there and needs to be installed. – Oxwivi Nov 05 '11 at 05:06
5 Answers
34
There's a slightly hackish, but quite reliable way to do this which I've been using for a while in an automated installation script.
First create a directory, for example /root/fake, which contains symlinks to /bin/true called:
initctl
invoke-rc.d
restart
start
stop
start-stop-daemon
service
deb-systemd-helper
You could also make them bash scripts that do nothing and return success.
Then include that directory at the front of $PATH when installing packages:
PATH=/root/fake:$PATH apt-get install whatever
This only prevents daemons from starting/restarting, while things like creating an initramfs are still being done.
Explanation
The scripts which are being executed at package installation and removal execute invoke-rc.d or others of the mentioned commands to start and stop services. They don't however call them with absolute paths (at least I haven't encountered one that does).
So by inserting the faked "no operation" commands at the beginning of $PATH, the real commands never get called.
Since only the commands used to start/stop services are being faked, everything else, in particular important tasks like updating/creating initramfs-images still work.
-
Not quite familiar with symlinks, can you elaborate with all the steps you take? – Oxwivi Nov 09 '11 at 18:47
-
A symlink is a special type of file that has no content, instead it refers to another file (by path/name). They can be created with `ln -s`, in this case for example `ln -s /bin/true /root/fake/initctl`. – bseibold Nov 09 '11 at 20:18
-
How does it prevent daemons from starting/restarting? According to @psusi's answer `invoke-rc.d` is responsible. – Oxwivi Nov 10 '11 at 07:08
-
By placing the directory with the faked commands at the beginning of the `$PATH` variable, all calls to `invoke-rc.d` and others that can be used to start and stop daemons use the fake commands. That is, unless they are called with an absolute path, but I have never encountered this. – bseibold Nov 10 '11 at 14:00
-
Ah, now I see how it works - basically, the symlinks leads to dead ends. But what exactly is the `/bin/true` thing? And what of the rest of the commands involved in the packages? Won't they get thrown off-track by the specified `$PATH`? – Oxwivi Nov 10 '11 at 14:07
-
`/bin/true` is a do-nothing command that returns without error. When you're starting something without specifying an absolute path, the `$PATH` variable is used to search for that command. This is done from left to right, so in case of `invoke-rc.d` this always leads to `/bin/true` being called instead. Everything else works as usual. – bseibold Nov 10 '11 at 14:23
-
Thanks for taking your time to clarify all those points. (And if you can be bothered any further, please edit those into your answer) – Oxwivi Nov 10 '11 at 15:20
-
This is terrible advice. Not only because there exists a documented and thus official solution to stop services from starting (policy-rc.d exiting with 101) but also because your method will break (invoke-rc.d communicates with its caller via its exit status, programs with hardcoded paths will fail, see https://bugs.debian.org/375183). This is a hack that probably works most of the time but as a hack and not the proper solution it should not be the most upvoted answer. – josch Mar 10 '20 at 08:14
-
@josch, this answer was written in 2011. Did `policy-rc.d` even exist back then? Regardless, it would be more helpful if you just updated the answer instead of complaining about it being terrible advice. – bseibold Mar 10 '20 at 12:44
-
@bseibold yes. It existed since at least 2001. If you agree, I will edit your answer with the correct solution. Do you agree? – josch Mar 10 '20 at 20:24
29
Background daemons are started with invoke-rc.d, which makes sure that the daemon is not started if its rc script says it is not supposed to run in the current system runlevel. You can override its idea of the current system runlevel by setting the environment variable RUNLEVEL. Nothing is supposed to run in runlevels 0 and 6, but it appears that invoke-rc.d is buggy and runs things anyhow if you use these runlevels. Most daemons do not run in runlevel 1, so you can prevent them from being started on install like this:
sudo RUNLEVEL=1 apt-get install redis-server
psusi
- 37,033
- 2
- 68
- 106
-
I'm installing minimal Ubuntu on a drive, then instead of booting into it, I use a Live CD/USB to `chroot` and install the packages I need. Because of the things starting to run, sometimes I'm switched out of the ubuntu (live CD) session. Anyway, the thing I want to ask is, how do I use this `RUNLEVEL` in `chroot`? – Oxwivi Nov 05 '11 at 11:43
-
@Oxwivi, the same way, but it is supposed to automatically detect you are in a chroot and skip starting daemons. – psusi Nov 07 '11 at 14:43
-
Is it possible the buggy `invoke-rc.d` is responsible for the issues I faced? – Oxwivi Nov 07 '11 at 15:24
-
@Oxwivi, it is possible, but more likely that a particular package is buggy and isn't using `invoke-rc.d`. What package was this? – psusi Nov 07 '11 at 15:29
-
I have no idea, I just listed all the packages to install and did not mind the terminal further to view the output. – Oxwivi Nov 07 '11 at 16:08
-
1Nice idea, but it doesn't work for me. `sudo RUNLEVEL=1 apt-get install lighttpd` still fails with `can't bind to port: 80 Address already in use` – jcsahnwaldt Reinstate Monica Jun 11 '13 at 15:54
22
There is a better solution:
cat > /usr/sbin/policy-rc.d <<EOF
#!/bin/sh
exit 101
EOF
chmod a+x /usr/sbin/policy-rc.d
Arseni Mourzenko
- 4,452
- 5
- 18
- 34
GnunuX
- 221
- 2
- 2
-
5This is the proper solution but unfortunately, not complete. Firstly, `/usr/sbin/policy-rc.d` might already exist and this solution does not check for that. Secondly, other packages might ship their own `/usr/bin/policy-rc.d` so you should dpkg-divert to protect against that. Lastly, by FHS policy you should not yourself put stuff into /usr/sbin. Instead the packages policy-rcd-declarative and policyrcd-script-zg2 will let you manage /usr/sbin/policy-rc.d in a declarative way. – josch Mar 10 '20 at 08:18
-
1Does this still work for current (systemd based) versions? The man page for invoke-rc.d says that it is used for System V style init scripts... – Gert van den Berg Dec 20 '22 at 21:05
5
What I ended up doing is emulating what debootstrap does when installing packages, except I used dpkg-divert:
First move the real files out of the way:
dpkg-divert --add --rename --local /sbin/start-stop-daemon
dpkg-divert --add --rename --local /sbin/initctl
Then create dummy versions:
echo \
"#!/bin/sh
echo
echo \"Warning: Fake start-stop-daemon called, doing nothing\"" > "/sbin/start-stop-daemon"
chmod 755 "/sbin/start-stop-daemon"
echo \
"#!/bin/sh
echo
echo \"Warning: Fake initctl called, doing nothing\"" > "/sbin/initctl"
chmod 755 "/sbin/initctl"
Then do your apt-get upgrades, installs, etc., and then clean up with:
rm /sbin/initctl /sbin/start-stop-daemon
dpkg-divert --remove --rename /sbin/initctl
dpkg-divert --remove --rename /sbin/start-stop-daemon
I know there are other commands that can be used to stop/start services, but debootstrap only cares about start-stop-daemon and initctl, so I followed suit.
Tal
- 59
- 1
- 3
3
A quick one-liner:
echo -e '#!/bin/sh\nexit 101' | install -m 755 /dev/stdin /usr/sbin/policy-rc.d && apt-get install **Package** && rm -f /usr/sbin/policy-rc.d
-
With regards to the person who put the "quick one-liner", you forgot to set /usr/sbin/policy-rc.d as executable. It'll be ignored otherwise. – Sep 10 '13 at 20:19