The subcommand of systemctl is only around the service start / stop reload, and although there are strangely many prepared subcommands, there are many points that I do not understand because the important subcommands are insufficient and the naming and behavior are delicate. I summarized it.
| Thing you want to do | COMMAND | active | inactive |
|---|---|---|---|
| I want to start it | systemctl start xxx | do nothing(exit 0) | start (Starting,Started) |
| I want to stop | systemctl stop xxx | stop (Stopping,Stoped) | do nothing(exit 0) |
| Restart if running, start if stopped | systemctl restart xxx | restart (Stopping,Starting,Started) | start (Starting,Started) |
| Reboot if running, do nothing if stopped | systemctl try-restart xxx | restart (Stopping,Starting,Started) | do nothing(exit 0) |
| Reload if running(Unit reload support required), Error if stopped | systemctl reload xxx | reload (Reloaded) | error(echo "Job for xxx.service invalid." >&2; exit 1) |
| Reload if running(Restart if Unit does not support Reload), Start if stopped | systemctl reload-or-restart xxx | reload (Reloaded) | start (Starting,Started) |
| Reload if running(Restart if Unit does not support Reload), Error if stopped | systemctl reload-or-try-restart xxx | reload (Reloaded) | error(echo "Job for xxx.service invalid." >&2; exit 1) |
| Reload if running(Restart if Unit does not support Reload)Do nothing if stopped | if systemctl -q is-active xxx; then systemctl reload-or-restart xxx; fi | reload (Reloaded) | do nothing(exit 0) |
--Cousin to praise
--It's a bit smarter than in the SysVinit era, as it behaves like doing nothing if it's not needed by looking at the status of start and stop being up or down.
--In the SysVinit era, restart was an image of ignoring the pre-state and executing stop and start roughly, but with systemctl, if it is in the stopped state, it behaves as if only start is executed without unnecessary stop. A little clever. Internally, maybe just calling stop / start shows the benefits of making stop / start smarter in restart as it is.
--I'm happy to be able to do reload-or-restart. In the days of SysVinit, I often wrote a one-liner that checks the status and uses reload and restart properly. Hmm? But this behavior is a little different from the name ...?
--Cousin to complain
――The impression and behavior of the word try-restart is different, isn't it? When I was told to try restart, I got the impression that "Ignore the pre-status and try restarting stop, start for the time being", but in reality, depending on the pre-status, "Restart (stop, start) if it is running, and already If it is stopped, it will end normally without stopping and doing nothing. "Rather, it behaves subtly intelligently. No, the behavior itself is good because I often want this kind of behavior, but I'm only interested in the name ... Is it okay if it's the feeling of a native English speaker? this. Am I wrong in understanding my try?
-- reload-or-restart is illogical and confusing, isn't it? ~~ What you are doing is reload-or-start, right? ~~ Ah! Does this restart mean to start when it is not running, but if the Unit does not support Reload, it means to execute restart instead of reload! But then, when it's not running, get the same error as when reloading! How many times did you start it! ?? It's illogical and confusing when you look at it as a whole! Maybe reload-or-restart behaves like an error when it's not running, and reload-or-restart-or-start separately. I think I should have created a subcommand with a name like and made it behave like the current reload-or-restart, though there is no such subcommand. Besides, if I change the behavior now, compatibility will not be maintained and problems will occur, and it's okay because it's a later festival ...
――Why doesn't "reload if it's running (restart if the unit doesn't support reload), do nothing if it's stopped"? ?? There will be a scene to use it. I'm always writing this one liner.
――I don't understand the meaning of the word try-restart again ... Why does try-restart do nothing while stopped and end normally, but reload-or-try-restart causes an error when stopped? Isn't the name and behavior of the subcommands too different overall? Based on SysVinit or Upstart, is it the resource management mechanism that came out at the moment? What's this unsophisticated feeling ...
legacy alias that appears in bash-completion to disappear from the completion candidates.The following subcommands existed by the convention of some distributions, but when they are put together in systemctl, the following corresponding aliases are internally defined as legacy alias and can be accepted and used, but basically He doesn't use it.
These subcommands do not appear in the list of systemctl --help, but they are treated as if they were on man. Basically, I don't need it, but in completion such as bash-completion, it usually appears as a subcommand in the list. Because of this, even for free, there are many service-related subcommands and it is difficult to understand, but "What is the difference between cond reload and reload? Help ... I found out when I looked at the man around! It's a free alias! Time to check! I think it wasted the resources of engineers all over the world, and I want them to be confused and annoyed and disappear from the complementary list. Isn't there a case where you dare to complement this and use it?
No, I know that there are many good points in terms of mechanism compared to various things in the past, but I'm surprised that the subcommand group of the service operation system that I use most often is subtle. Maybe I don't care because I only use status / start / stop / restart / reload if I just use it normally. When creating ansible configuration file, when you want to use reload or start properly while checking the status in advance, or when you want to judge the ideal status appropriately by the exit status, the subcommand name is logically organized and remembered I can't do it, and the behavior is sloppy, so I'm worried and I end up writing while checking the document and the actual behavior every time.
Recommended Posts