On 17.11.2015 17:51, m.roth@xxxxxxxxx wrote:
> Nick Bright wrote:
>> On 11/17/2015 8:18 AM, James B. Byrne wrote:
>>> This behaviour is congruent with SELinux. One utility adjusts the
>>> permanent configuration, the one that will be applied at startup.
>>> Another changes the current running environment without altering the
>>> startup config. From a sysadmin point of view this is desirable since
>>> changes to a running system are often performed for empirical testing.
>>> Leaving ephemeral state changes permanently fixed in the startup
>>> config could, and almost certainly would eventually, lead to serious
>>> problem during a reboot. Likewise, immediately introducing a state
>>> change to a running system when reconfiguring system startup options
>>> is just begging for an operations incident report. It may not be
>>> intuitive to some but it is certainly the logical way of handling this.
>>
>> I certainly don't disagree with this behavior.
>>
>> What I disagree with is documented commands _*not working and failing
>> silently*_.
>>
> I agree, and it seems to be the way systemd works, as a theme, as it were.
> I restart a service... and it tells me *nothing* at all. I have to run a
> second command, to ask the status. I've no idea why it's "bad form" to
> tell me progress, and final result. You'd think they were an old New
> Englander.....
Systemd has better mechanisms to report feedback compared to SysV
scripts but if the creators of the service files and the daemons don't
make use of these that's hardly systemd's fault. The best way is to use
"Type=notify" which allows a daemon to actually report to systemd when
it is done initializing. If the daemon doesn't support this then you can
still use ExecStartPost to specify a command that verifies that the
daemon indeed did start up correctly (and no the binary returning a code
of 0 does not mean the service is actually up-and-running properly).
Regards,
Dennis
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
