On 05/22/14 at 02:02pm, Vivek Goyal wrote:
On Mon, May 19, 2014 at 10:42:23PM +0800, WANG Chao wrote:
> dracut-emergency.service is conflicting with emergency.service:
>
> "Conflicts=emergency.service emergency.target"
>
> We should always disable dracut-emergency.service. Because if it gets
> started, our emergency.service will be interrupted and stopped.
>
> And also dracut-emergency.service isn't useful now, since we introduced
> our own error handler.
>
> Signed-off-by: WANG Chao <chaowang(a)redhat.com>
> ---
> dracut-kdump.sh | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/dracut-kdump.sh b/dracut-kdump.sh
> index d092e04..eb4ab42 100755
> --- a/dracut-kdump.sh
> +++ b/dracut-kdump.sh
> @@ -4,10 +4,6 @@ exec &> /dev/console
> . /lib/dracut-lib.sh
> . /lib/kdump-lib.sh
>
> -if [ -f "$initdir/lib/dracut/no-emergency-shell" ]; then
> - rm -f -- $initdir/lib/dracut/no-emergency-shell
> -fi
> -
I guess we want to cleanup putting no-emergency-shell file also in
dracut-module-setup.sh.
No. This patch isn't about cleanup no-emergency-shell. It's about
disable it forever in 2nd kernel.
install() {
kdump_install_conf
"$initdir/lib/dracut/no-emergency-shell"
Or you have already done it in other patches?
No, we should do that. The point is we should never enter
dracut-emergency. So we always disable this feature by:
install() {
...
"$initdir/lib/dracut/no-emergency-shell"
As I pointed out, because dracut-emergency.service "Conflicts=" with
emergency.service, when it gets started, our emergency.service will be
stopped.
The other reason to disable dracut-emergency is it's totally useless. We
should only left one emergency handler in our system, ie. kdump error
handler.
Thanks
WANG Chao