[Fuego] [PATCH] Add test cases of service multipathd.

[Wang, Mingyu]

Hi Tim,

I tried the system using sysvinit and found that there is a problem that the status option of the service cannot obtain the return value correctly. There are two cases: 
1. There is no status option defined in service files, so the service status XX cannot get the status of the service (such as acpid). 
2. Even if the status option is defined in the service file, the service will not generate a pid file, so the correct status of the status will not be obtained (such as openct). 

For the above two cases, the status of the service cannot be judged before the test is executed, so the status of the service cannot be restored after the test is completed.
Is it need to skip the test of above two cases in the sysvinit environment?
If you have any good suggestions, please let me know. 

In addition, not all environments have the command service, maybe it’s better to use /etc/init.d.

by Wangmy.

-----Original Message-----
From: Tim.Bird at sony.com [mailto:Tim.Bird at sony.com] 
Sent: Friday, January 11, 2019 7:04 AM
To: Tim.Bird at sony.com; Wang, Mingyu/王 鸣瑜 <wangmy at cn.fujitsu.com>; fuego at lists.linuxfoundation.org
Subject: RE: [Fuego] [PATCH] Add test cases of service multipathd.



> -----Original Message-----
> From: Tim.Bird at sony.com
> 
> Same comments as other patches.
> 
> 'is-active' is only supported by systemctl (when init_manager is 
> 'systemd')
> 
> Let's fix that issue, and rework these patches with the solution we 
> decide upon.

I was just looking at fuego_board_function_lib.sh and saw this:
exec_service_on_target() {
    if [ "$init_manager" = "systemd" ]
    then
        systemctl $2 $1
    else
        $1 $2
    fi
}

This doesn't seem right.  Has this library been used for testing on a non-systemd platform?

I'm pretty sure that the command after the 'else' should be one of the following:
  service $1 $2
or
 /etc/init.d/$1 $2

For example, on a system I have here built with Yocto Project:
$ dropbear status
(no result)
$ /etc/init.d/dropbear status
Usage: /etc/init.d/dropbear {start|stop|restart|force-reload} $

Which shows that the dropbear binary executed by itself doesn't perform the start/start operations. It's the init script in /etc/init.d that does this.  Also, that init script (the one for dropbear) doesn't support the 'status' operation.

So, I think that 'status' is not a well-supported operation for embedded Linux services (at least on systems that are using sysvinit as the init manager).
So maybe this whole is_active thing needs to be re-thought.

Maybe it's acceptable to just say that these tests are dependent on the system-under-test using 'systemd'.  Or, maybe the legacy init scripts for these particular services do all support the 'status' operation.

I think it was Fujitsu that introduced this concept of providing an abstraction for service management into Fuego.  Is Fujitsu using systems without systemd?
It doesn't look like this exec_service_on_target would work on non-systemd systems.

Let me know your thoughts.
 -- Tim