On Tuesday 02 September 2014 01:33 PM, Ritesh Raj Sarraf wrote:
Could you elaborate a bit more, why those are needed?
What is upstream doing about this?
The block storage has many components that work closely with one another.
Take an example, root fs on LVM on Multipath on iSCSI.
The flow for such a setup is to:
1) Start iSCSI and discover the LUNs
2) Detect and create mulitpath maps for matching LUNs in DM Multipath
3) Detect and Activate Volume Group out of the newly detected DM
Multipath Physical Volumes
4) Mount the file system.
The same can be applied to the shutdown sequence. You want to have
proper checks in place before initiating a shutdown of the service.
One would argue that the service should not stop if it has active
services.
Many of the services (mulitpath, iscsi, for example) have a 2 part
component. One in the kernel and the other in userspace. The kernel
space service will not terminate if any service is active. But the
userspace is not so forgiving.
In open-iscsi, if you ask the daemon to shutdown, it will. If there
are active sessions, the kernel component will not terminate the
current sessions. But the userspace daemon will be shutdown. That
means, that when there is the next state failure, open-iscsi will have
no idea of determining that a LUN state has changed
Similar is the case with DM Multipath. The userspace DM Multipath
daemon is responsible for polling and keeping an up-to-date status of
the Device Mapper maps. If the userspace daemon is inactive, and
underneath there is a fabric state change, there is no way to
propagate that error to the upper layers.
These design issues, since they are part of the core storage stack, if
triggered, leave you with a machine with no access to your root disk.
Any process at that time, may get into a 'DI' process state or an
immediate device failure. The only action then would be to hardware
reset your machine.
This is why we do a lot of checks in the init scripts to warn the user.
Similar approaches were taken in RHEL (5 and 6) and SLES (10 and 11).
I'm not sure what Red Hat or SUSE has chosen for their latest
releases, as I don't work on those products any more.
My inclination is to ship both, the systemd service files and the init
scripts, in their current form along with whatever limitations each
may have, and let the user choose.
Hi,
I did not get any comment on this. How are others doing similar stuff
while migrating to systemd ?
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5406df56.6070...@debian.org