First log in to the database server as the db2instance owner(su – is fine if you’re coming from root). This is the id you specified as the DBA on commerce build. Frequently the default is db2inst1.

Try stopping db2 cleanly using simply

This will fail if there are any connections left. If it does fail, do:

$ db2 list applications

This provides a list of connections to your database. If there are many, go back and make sure you stopped all applications properly. For any remaining connections, make sure there’s no reason you can see that forcing the connections off will fail. Then try this:

If that doesn’t succeed, there’s one more drastic command you can find that will work, but it’s rare that db2stop force doesn’t work. It may take a bit longer on an active database, as it has to make any remaining connection roll-back their units of work.

Stop the DB2 Administration Server (DAS)

I rarely actually use the DAS, but I always create it on build so it’s out there if I or anyone else needs it. To stop it, you must login as the DAS owner or su – to the DAS owner, and issue the following:

>db2admin stop

I’ve never seen that one fail

For all instances including the DAS, stop the db2 fault monitor

As the das owner (or su’d to it), issue:

db2fm -i <dasowner> -D

ignore any failures, as the failure usually just indicates that the fault monitor was not running in the first place.

As the instance owner (or su’d to it), issue:

db2fm -D

ignore any failures, as the failure usually just indicates that the fault monitor was not running in the first place.

Comment out db2 entry in /etc/inittab and kill any remaining processes

So there’s always one, and sometimes many processes hanging around at this point. One of these is owned by root, and is actually the result of a respawn in inittab. The line looks something like this:

Ember is always curious and thrives on change. Working in IT provides a lot of that change, but after 17 years developing a top-level expertise on Db2 for mid-range servers and more than 7 years blogging about it, Ember is hungry for new challenges and looks to expand her skill set to the Data Engineering role for Data Science. With in-depth SQL and RDBMS knowledge, Ember shares both posts about her core skill set and her journey into Data Science.
Ember lives in Denver and work from home for XTIVIA, leading a team of Db2 DBAs.

12 comments

Most Linux distributions support the following: “telinit q”. When run as root, this will perform something similar to “kill -HUP 1”

Note that the “telinit q” method is going to be preferable to other methods (at least for Linux) because it works even if your system is not using System V-style init. If, for example, you’re using the new Upstart boot system, compatibility wrappers like telinit should still be available, even though the internals of the system may have changed.

Hi Ember,
I’ve had issues with db2fmcd on Linux RedHat 6.6 (it changed the way it uses inittab).
After trying everything I know, a friend of mine that is a Linux specialist told me I should run the following (as root):
initctl stop db2fmc
I did it and it worked fine. Just wanted to share here. Thanks for all the valuable info you share in your blog!

db2stop force will also deactivate the database for you. Deactivating the database may allow db2stop to work without the force parameter. You may have to force remaining applications off if they are still connected. Your method is certainly valid if it works, though if you are stopping db2 for something like a fixpack or upgrade, or OS maintenance, you’ll need to include stopping the DAS(if you have one), the fault monitor, and commenting out the inittab entry.

Hi,
Issuing command “db2fm -D” with a still running db2fmcd has little effect; “db2fm -D” will sequentially send kill, kill -15 and kill -9 to the fault monitor daemon, which then will be killed, but after a short while will be started again by the db2fmcd. So you have to issue the “db2fm -D” command(s) after removing the fmc-entry from the inittab.