mjhjmtu

Actually not debian, but Raspbian Wheezy to Raspbian Jessie.
I upgrade it using some commands which found on Raspbian official forum.

cat /etc/debian_version = 8.0.

The problem is, I can't view any result when I restart the service.

Before upgrade(Wheezy):

# service tor restart
[ok] cccc
[ok] ddd
# _

After upgrade(Jessie):

# service tor restart
# _

And all results are written to /var/log/syslog...
How can I revert this thing? I want to see actual result, not written to log.

service is now handled by systemd, and systemd is quiet when everything goes well. There doesn't seem to be a way to change that. Lennart added a TODO item to add a verbose mode restoring behaviour similar to what you're after, but three years later it's still in the TODO list!

You could always define a shell function to do something like

service tor restart && echo '[OK]' || echo '[Failed]'

(with tor replaced by $1, and whatever message you want in the echo commands), but that won't give you details of units running multiple commands.

systemctl status tor

will show you the detailed status of the relevant unit, so another option could be to couple that with start or restart.

A lot of services on error, some services always return sucess, even if the service not started, because systemd is starting a kind of service manager instead of the service itself..... And no dont trust service status about what hapenned I get a lot of times a "STARTED OK" and service is really not running without any feedback! So it still does not solve the problem! But is better if you run journal -xe lot better than doing this, but not good enough because you need to run it everytime and remember of it. – @Luciano Andress Martini

"No result" means the operation succeeded. This is the UNIX default. It is how the cp or rm commands behave, for example.

If your service is written incorrectly, it may return success and then fail immediately afterwards e.g. when it reads a bad configuration. This is a bug in the service! If a sysvinit script behaves like this, you would have exactly the same problem! There is nothing systemd can do to fix that.

When your unit fails, there is a trick to view the last 10 lines from your daemon only. Run systemctl status as the root user (i.e. sudo). Alternatively, you can add your user as a member of one of the groups systemd-journal or adm.

When I need more than the last 10 lines, I use journalctl -u tor -b, meaning everything from the current boot. Or if you have restarted it many times during the current boot, you might want to use journalctl -u tor --since=-1hour. Or for short, --since=-1h.

I think systemctl already suggests you run systemctl status when the unit fails to start. (Unfortunately, systemctl never mentions the permissions issue).

systemctl does also suggest journalctl -xe. Personally, I think this is unhelpful. -x mostly just adds a lot of noise. -e skips e.g. stdout/stderr messages and anything else that is not explicitly marked as an error message. (It even skips stderr messages, sorry. Changing this is awkward: it would allow stderr lines to be re-ordered v.s. stdout, which might be undesirable for shell scripts).

There is a similar user complaint on the systemd issue tracker, which involves some other services which are buggy. (Or, one of them looks like it might be deliberately failing "in the background", after a long network timeout. Again, this is exactly how the service is written, it is not systemd trying to annoy you).