We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Help IBM prioritize your ideas and requests
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Receive notification on the decision
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.
Make TSA start DB2 under system.slice, in order to gracefully stop/takeover databases on shutdowns/reboots.
Since init was replaced by systemd as the linux main process (in 2014 !), it makes huge difference the way DB2 is started. At server shutdown or reboot, the user processes are all killed, and only then systemd starts to stop the services. This behavior is hardcoded. And the way TSA (or TSAMP ?) starts DB2 put it under the "user.slice" control group. It means systemd kills all DB2 processes at the first action when a sysadmin states a shutdown or reboot.
We have some DB2 HADR clusters automated using TSA and db2haicu. Our sysadmins boot all the servers once or twice a month, in order to install OS fixes. They are planned shutdowns, but the DB2 processes are simply killed. Then, TSA tries to restart them, and finally TSA is killed too, and server reboots without properly shutdown or takeover the databases to the peer.
Log on each server and using "db2haicu" or "db2 takeover db..." is not practical, and prevent our sysadmins from using they standard automated tools. I'm worried about this because killing processes is not the correct way to stop a database. We are unnecessarily exposing our databases to corruption factors, and sometimes the TSA itself shows malfunctioning because it didn't have time to gracefully stop before server goes off.
Writing an unit file "db2.service" with "ExecStop=..." is not enough, because DB2 is killed before the first stop script is called (systemd hardcoded behavior). I opened a case on RedHat asking for a way to gracefully stop DB2, but the response was that is impossible under user.slice, and: "I recommend speaking to DB2's vendor in order to request its service to be changed in a way it is correctly managed by systemd. ... because all within user.slice is considered non-critical ... there's little that can be done on the OS level. This truly is an application issue"
In a short way: TSA starts DB2 in systemd's user.slice, could it starts in system.slice?
Do not place IBM confidential, company confidential, or personal information into any field.