Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory

[Ritesh Raj Sarraf]

On Monday 01 September 2014 07:48 PM, Michael Biebl wrote:
>> In native init scripts, we did a lot of check before starting and
>> >shutting down the daemon. Things like checking the root device, or
>> >tiggering LVM Volume Group activitation. They were easily done in shell.
>> >
>> >What would the systemd team recommend for it ?
>> >
> 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.


And by the way, can someone please shed some more light on Debian bug: 
760182

Per the bug report, there is no systemd support in d-i. Which then means 
that I need to disable systemd support ?


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System