On Mon, November 16, 2015 16:39, Nick Bright 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.
On Tue, Nov 17, 2015 at 09:18:22AM -0500, James B. Byrne wrote:
Another possible reason is because when you're setting up firewalld, you might want to batch a bunch of changes with --permanent, then, once you've added them all, *then* you restart firewalld to pick up the changes. Having the firewall restart after *every* permanent change you want to make would leave the system's firewall bouncing up and down.
On 17.11.2015 15:18, James B. Byrne wrote:
The better way is to explicitly allow the user to dump the runtime configuration as the persistent configuration though as that makes it much more difficult to have subtly diverging configurations due to user errors. On network switches you often find something like "copy running-congig startup-config".
Regards, Dennis
On 11/17/2015 8:18 AM, James B. Byrne wrote:
I certainly don't disagree with this behavior.
What I disagree with is documented commands _*not working and failing silently*_.
Nick Bright wrote:
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.....
mark, ayu'
On Nov 17, 2015 12:11 PM, m.roth@5-cent.us wrote:
_____________________________
Totally hilarious. Thanks for making my day.
Mike
On 17.11.2015 17:51, m.roth@5-cent.us wrote:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 17/11/15 17:29, Dennis Jacobfeuerborn wrote:
You may well be right. However for those of us who just want to get the system running it has lousy reporting. Under SysV setting -vx on the script gave meaningful output - there's no easy equivalent under systemctl. Systemctl returning success status on daemon failure is plain stupid. I'm sure systemd does wonderful things and is the future and we're stuck with it now until at least CentOS/RHEL 8. One of the great joys of *NIX is small, stable text files that can be handled without vast study unlike the obscure behemoth that would look good coming out of Redmond. Even getting ntp to supply time to another system takes hours instead of 5 minutes.
If I ever meet Poettering I'll be sure to sup with a long spoon. ;-(
J Martin Rushton wrote:
<snip>
Actually, I think I've figured out why systemd... let's see, the CEO of upstream was CEO of Delta Airlines before he came to RH (?!), and now this....
mark
-
Dennis Jacobfeuerborn -
J Martin Rushton -
James B. Byrne -
Jonathan Billings -
m.roth＠5-cent.us -
Mike -
Nick Bright