Re: No feedback from systemd / "systemctl stop X"... Nothing on stdout, nothing that `echo $?` can see...
On Thu, Mar 12, 2015 at 01:44:23AM -0300, Martinx - ジェームズ wrote:
> On 12 March 2015 at 01:13, Don Armstrong <don@debian.org> wrote:
> >
> > On Wed, 11 Mar 2015, The Wanderer wrote:
> > > Running those commands doesn't give you output from 'systemctl stop
> > > foo' or the like, however.
> >
> > > I thought the OP was asking how to determine, from the exit code
> > > and/or the console output of 'systemctl stop foo' (or a similar
> > > command, one that actually _alters_ the status of a service), whether
> > > the command actually succeeded.
> >
> > If you want to know that, then do something like:
> >
> > systemctl start foo && systemctl is-active foo;
> >
> > or
> >
> > systemctl stop foo && ! systemctl is-active foo && ! systemctl is-failed \
> > foo;
> >
> > Presumably you could even write a shell function to do this if that's
> > something that you actually wanted.
> >
> > > You can certainly run these commands afterwards, and get the status of
> > > the service that way, but that's no substitute for being able to get
> > > output or the like directly from the original control command.
> > >
> > > Does systemd really not provide any "verbose" mode for its
> > > service-control commands, in which they report what they are doing?
> >
> > No. Really, all systemctl start/stop do is tell systemd to actually stop
> > or start the service, and optionally block until the action is
> > completed.
> >
> > I suppose someone could make an argument that including a verbose flag
> > or something might be useful, but considering that you can achieve
> > similar functionality with existing discrete tools, I'm not sure that
> > growing additional code and documentation to support such an option is
> > worth it.
> >
> > Look at the definition of start_unit in
> > http://cgit.freedesktop.org/systemd/systemd/tree/src/systemctl/systemctl.c
> > for the current code.
> >
> >
> > --
> > Don Armstrong http://www.donarmstrong.com
>
> Hey guys!
>
> Thanks for all the replies! I really appreciate it.
>
> Now, I'm understanding more about it, I'm fine with "is-active |
> is-failed" systemd options.
>
> Nevertheless, I think that it is weird that systemd is very different
> from what I've experienced in the past 20 years. For example, why the
> service's configuration files are stored at
> "/lib/systemd/system/*.service" and not directly under /etc? For God's
> sake...
This is by design, and working around limitations in RPM (afaik). The
systemd-package-supplied service scripts are in /lib/systemd/…; if they are
modified upstream and you update your systemd package, they can be updated
safely (no risk of overwriting user modifications). If you want to modify them
locally, copy them to /etc/systemd/… first. These take precedence over the
copies in /lib/systemd/…, and will not be overwritten by a future system update
to systemd.
> I thought that Debian had rules to organize its file system.
Yes, the FHS, but the above does not break the FHS anyway. Of course on a
Debian system, dpkg can alert you that the incoming systemd update was going to
change a file which you have locally modified; but even in Debian we aren't
consistent in how we handle this, and that forces interactive upgrades for core
packages.
> For example, with CentOS / RedHat, when you install "httpd", it puts a
> symlink under /etc/httpd pointing to /var/log
I don't see a problem with that. Upstream expect /etc/httpd/log, RH honour that
but ensure the actual logs go to /var, as per FHS. I prefer Red Hat's apache
going to /etc/httpd over Debian's to /etc/apache2, personally…
Reply to: