On 03/30/17 at 09:53am, Baoquan He wrote:
On 03/30/17 at 09:49am, Xunlei Pang wrote:
> On 03/30/2017 at 09:38 AM, Baoquan He wrote:
> > On 03/27/17 at 12:07pm, Xunlei Pang wrote:
> >> This will lead to systemd two contradictable jobs queued as an
> >> atomic transaction:
> >> job 1) the emergency service gets started by initrd-root-fs.target
> >> job 2) the emergency service gets stopped due to "systemctl
isolate"
> >> thereby throwing "Transaction is destructive".
> >>
> >> In order to solve it, we can utilize "IgnoreOnIsolate=yes" for
> >> both kdump-emergency.service and kdump-emergency.target to avoid
> >> being isolated, then they can keep going on as expected in case
> >> of failures.
> > A small concern. Above paragraph, IgnoreOnIsolate is newly introduced
> > option, we could make it clearer for later reviewing if forget. How
> > about writing it like:
> >
> > In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
> > kdump-emergency.service and kdump-emergency.target. Service or target
> > with attribute "IgnoreOnIsolate=yes" won't be stopped by other
service
> > /target being isolated, then they can keep going as expected in case be
> > triggered by any failure.
> >
> > Here, not sure if we can use systemd unit instead of service/target. I
> > feel systemd unit is not appropriate here.
>
> Unit is ok, it's a general concept for service, target, mount, socket, ...
>
> In order to solve it, we can utilize "IgnoreOnIsolate=yes" for both
> kdump-emergency.service and kdump-emergency.target. Unit with attribute
> "IgnoreOnIsolate=yes" won't be stopped when isolating another unit,
> they can keep going as expected in case be triggered by any failure.
Yeah, agree. Better say systemd unit here. Otherwise this looks good to
me. Dave could replace with these directly when merge since He and
Pratyush have acked.
Added in the commit..
Thanks
Dave