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. > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
