[systemd-devel] after=local-fs not enforced

[Andrei Borzenkov]

25.11.2016 18:13, Benoit SCHMID пишет:
> Hello,
> 
> On 11/25/2016 04:47 AM, Andrei Borzenkov wrote:
>> Yes, this is the command that tries to unmount filesystems on LVM2
>> devices, thus bypassing systemd normal dependencies. The idea of such
>> service is very questionable, but it is probably not something you can
>> really change.
>>
>> You can try to add drop-in to order this service after
>> systemd-logind.service on shutdown, but I would contact RH and verify
>> that they agree to support this. In any case, this is not systemd issue.
> 
> A quick and dirty way of avoiding this is to add the following.
> After=blk-availability.service in my service.
> 
> Do you see any drawbacks by setting this?
> 

Not really. It should help with disappearing filesystems in your case.

> In most case, Linux admin should not see this umount problems
> because busy fs are not unmounted.
> On a SAP system running on Oracle you should always get the error.
> Because the oraarch is not busy except when the DB archives a redolog.
> Therefore blk-availability succeeds to umount oraarch because it is empty.
> Then SAP forces the archive of the current redolog.
> Then it needs to access this fs that has been unmounted:
> ###
> Stopping background process SMCO
> Thu Nov 24 14:51:59 2016
> Errors in file
> /oracle/XXX/saptrace/diag/rdbms/xxx/XXX/trace/XXX_arc2_12953.trc:
> ORA-19504: failed to create file
> "/oracle/XXX/oraarch/xxxarch1_530_927368778.dbf"
> ORA-27040: file create error, unable to create file
> Linux-x86_64 Error: 13: Permission denied
> Additional information: 1
> ARC2: Error 19504 Creating archive log file to
> '/oracle/XXX/oraarch/XXXarch1_530_927368778.dbf'
> ###
> 
> Honestly, what is disappointing is that RH does not consider LVM fs as
> local-fs.
> Now that I understand the problem, I consider this not a systemd problem,
> but rather a lvm systemd integration problem.
> What is frustrating, is that I have been having a call opened, for that,
> with RH, for more than two weeks.
> The only answer I got is : We are working on it :-(

What makes you think they are not? :) Anyway you can update them and
point to exact problematic service.

> But this is neither a systemd problem :-)
> 
> Thanks in advance for your answer.
>