Bug#806291: systemd: systemctl status ignores -n argument
Control: close -1 On Thu, 26 Nov 2015 08:00:16 +0100 Eduard Bloch wrote: > Package: systemd > Version: 228-2 > > Dear Maintainer, > > * What led up to the situation? > > I created a buggy configuration of apt-cacher-ng and wondered why it did not start. When I run the service from command line, it dumps a couple of usefull hints to STDERR. I expected to see this in "systemctl status" output. I saw only ten lines and this contained only useless cruft, something about "hold-off time over" etc. This is caused by missing kernel functionality and is already tracked upstream, nothing we can do downstream, closing. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#806291: systemd: systemctl status ignores -n argument
On Sun, Dec 20, 2015 at 02:52:49PM +0100, Eduard Bloch wrote: > Hallo, > * Zbigniew Jędrzejewski-Szmek [Mon, Nov 30 2015, 01:25:49AM]: > > > > [Service] > > > Type=notify > > > Restart=on-failure > > > ExecStart=/bin/sh -c "echo OMG THEY KILLED KENNY >&2; exit 123" > > > > > > and check the result: > > > > > > foo.service - SomeThing > > >Loaded: loaded (/lib/systemd/system/foo.service; disabled; vendor > > > preset: enabled) > > >Active: failed (Result: start-limit) since Sa 2015-11-28 11:28:39 CET; > > > 13s ago > > > Process: 6982 ExecStart=/bin/sh -c echo OMG THEY KILLED KENNY >&2; exit > > > 123 (code=exited, status=123) > > > Main PID: 6982 (code=exited, status=123) > > > > > > Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. > > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. > > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result > > > 'exit-code'. > > > Nov 28 11:28:39 idefix sh[6982]: OMG THEY KILLED KENNY > > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Service hold-off time > > > over, scheduling restart. > > > Nov 28 11:28:39 idefix systemd[1]: Stopped SomeThing. > > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Start request repeated > > > too quickly. > > > Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. > > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. > > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result > > > 'start-limit'. > > > > > > > > > Looks good, huh? So what is the major difference to the script in the > > > original report? > > > Is it maybe this? > > > Type=notify > > > > There's a race for short-lived programs - if the process has exited by > > the time journald looks the sender up in /proc, it will not be able to > > assign the message the right systemd unit. This means that the message > > will be in logs, but it will not be shown by > > 'systemctl status unit'/'journalctl -u unit'. This race is currently > > unfixable, until kernel provides additional functionality to attach more > > metadata to messages. > > OMG. I was assuming that sd_notify is a mechanism designed to avoid such > kind of BS. Is there a public kernel bug report anywhere to check for > more details? https://bugzilla.redhat.com/show_bug.cgi?id=963620, links to lkml discussions start at comment 33. kdbus would also solve this, you can easily search for that. > Can I flush the log processing somehow from inside the unit process > itself? Not that I'm aware of. > > > But anyhow, it's a secondary issue and probably deserves a second bug > > > report. > > > The thing that botters me, see subject, is the broken -n option, adding > > > -n20 or > > > -n2000 to systemctl-status call does not change anything. It keeps > > > displaying 10 > > > lines. > > That's really strange. > > What is the exact command line that you are using? > > Does 'systemctl -n0 status ...' show any log lines? > > Basically any command. Let's pick the next example with useful logs from > "journalctl -b0" output... > > $ systemctl status virtualbox > ● virtualbox.service - LSB: VirtualBox Linux kernel module >Loaded: loaded (/etc/init.d/virtualbox; bad; vendor preset: enabled) >Active: failed (Result: exit-code) since Sa 2015-12-19 21:11:20 CET; 17h > ago > Docs: man:systemd-sysv-generator(8) > Process: 1312 ExecStart=/etc/init.d/virtualbox start (code=exited, > status=1/FAILURE) > $ systemctl status -n200 virtualbox > ● virtualbox.service - LSB: VirtualBox Linux kernel module >Loaded: loaded (/etc/init.d/virtualbox; bad; vendor preset: enabled) >Active: failed (Result: exit-code) since Sa 2015-12-19 21:11:20 CET; 17h > ago > Docs: man:systemd-sysv-generator(8) > Process: 1312 ExecStart=/etc/init.d/virtualbox start (code=exited, > status=1/FAILURE) > $ journalctl -b0 -u virtualbox > Hint: You are currently not seeing messages from other users and the system. > Users in the 'systemd-journal' group can see all messages. Pass -q to > turn off this notice. > No journal files were opened due to insufficient permissions. > > (same thing as root) > $ journalctl -b0 -u virtualbox > -- Logs begin at Mo 2015-07-27 19:58:37 CEST, end at So 2015-12-20 14:46:29 > CET. -- > Dez 19 21:11:19 zombie systemd[1]: Starting LSB: VirtualBox Linux kernel > module... > Dez 19 21:11:20 zombie virtualbox[1312]: Starting VirtualBox kernel modulesNo > suitable module for running kernel found ... failed! > Dez 19 21:11:20 zombie virtualbox[1312]: failed! > Dez 19 21:11:20 zombie systemd[1]: virtualbox.service: Control process > exited, code=exited status=1 > Dez 19 21:11:20 zombie systemd[1]: Failed to start LSB: VirtualBox Linux > kernel module. > Dez 19 21:11:20 zombie systemd[1]: virtualbox.service: Unit entered failed > state. > Dez 19 21:11:20 zombie systemd[1]: virtualbox.service: Failed with result > 'exit-code'. > > Ok, only NOW we see the caus
Bug#806291: systemd: systemctl status ignores -n argument
Hallo, * Zbigniew Jędrzejewski-Szmek [Mon, Nov 30 2015, 01:25:49AM]: > > [Service] > > Type=notify > > Restart=on-failure > > ExecStart=/bin/sh -c "echo OMG THEY KILLED KENNY >&2; exit 123" > > > > and check the result: > > > > foo.service - SomeThing > >Loaded: loaded (/lib/systemd/system/foo.service; disabled; vendor > > preset: enabled) > >Active: failed (Result: start-limit) since Sa 2015-11-28 11:28:39 CET; > > 13s ago > > Process: 6982 ExecStart=/bin/sh -c echo OMG THEY KILLED KENNY >&2; exit > > 123 (code=exited, status=123) > > Main PID: 6982 (code=exited, status=123) > > > > Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result > > 'exit-code'. > > Nov 28 11:28:39 idefix sh[6982]: OMG THEY KILLED KENNY > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Service hold-off time over, > > scheduling restart. > > Nov 28 11:28:39 idefix systemd[1]: Stopped SomeThing. > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Start request repeated too > > quickly. > > Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. > > Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result > > 'start-limit'. > > > > > > Looks good, huh? So what is the major difference to the script in the > > original report? > > Is it maybe this? > > Type=notify > > There's a race for short-lived programs - if the process has exited by > the time journald looks the sender up in /proc, it will not be able to > assign the message the right systemd unit. This means that the message > will be in logs, but it will not be shown by > 'systemctl status unit'/'journalctl -u unit'. This race is currently > unfixable, until kernel provides additional functionality to attach more > metadata to messages. OMG. I was assuming that sd_notify is a mechanism designed to avoid such kind of BS. Is there a public kernel bug report anywhere to check for more details? Can I flush the log processing somehow from inside the unit process itself? > So you should check with journalctl -u that the messages you think > should be shown are really attached to that unit. Probably... but: as a regular mortal I do what all the docs say. I run "systemctl status" and it doesn't report anything useful. The next obvious thing is adding -n and it doesn't help, hence this bug report. And see below. > > I can imagine that if the service dies before any dbus event was sent then > > the > > messages are printed early, followed by the spam I mentioned? And that makes > > them scroll out of "systemctl status" buffer? > > > > But anyhow, it's a secondary issue and probably deserves a second bug > > report. > > The thing that botters me, see subject, is the broken -n option, adding > > -n20 or > > -n2000 to systemctl-status call does not change anything. It keeps > > displaying 10 > > lines. > That's really strange. > What is the exact command line that you are using? > Does 'systemctl -n0 status ...' show any log lines? Basically any command. Let's pick the next example with useful logs from "journalctl -b0" output... $ systemctl status virtualbox ● virtualbox.service - LSB: VirtualBox Linux kernel module Loaded: loaded (/etc/init.d/virtualbox; bad; vendor preset: enabled) Active: failed (Result: exit-code) since Sa 2015-12-19 21:11:20 CET; 17h ago Docs: man:systemd-sysv-generator(8) Process: 1312 ExecStart=/etc/init.d/virtualbox start (code=exited, status=1/FAILURE) $ systemctl status -n200 virtualbox ● virtualbox.service - LSB: VirtualBox Linux kernel module Loaded: loaded (/etc/init.d/virtualbox; bad; vendor preset: enabled) Active: failed (Result: exit-code) since Sa 2015-12-19 21:11:20 CET; 17h ago Docs: man:systemd-sysv-generator(8) Process: 1312 ExecStart=/etc/init.d/virtualbox start (code=exited, status=1/FAILURE) $ journalctl -b0 -u virtualbox Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice. No journal files were opened due to insufficient permissions. (same thing as root) $ journalctl -b0 -u virtualbox -- Logs begin at Mo 2015-07-27 19:58:37 CEST, end at So 2015-12-20 14:46:29 CET. -- Dez 19 21:11:19 zombie systemd[1]: Starting LSB: VirtualBox Linux kernel module... Dez 19 21:11:20 zombie virtualbox[1312]: Starting VirtualBox kernel modulesNo suitable module for running kernel found ... failed! Dez 19 21:11:20 zombie virtualbox[1312]: failed! Dez 19 21:11:20 zombie systemd[1]: virtualbox.service: Control process exited, code=exited status=1 Dez 19 21:11:20 zombie systemd[1]: Failed to start LSB: VirtualBox Linux kernel module. Dez 19 21:11:20 zombie systemd[1]: virtualbox.service: Unit entered failed state. Dez 19 21:1
Bug#806291: systemd: systemctl status ignores -n argument
On Sat, Nov 28, 2015 at 11:37:55AM +0100, Eduard Bloch wrote: > Hallo, > * Michael Biebl [Thu, Nov 26 2015, 04:32:43PM]: > > Am 26.11.2015 um 15:59 schrieb Michael Biebl: > > > Works here. But I actually need a service which produces more then 10 > > > lines of output when started. > > > > To illustrate what I did: > > > > # cat /etc/systemd/system/output.service > > [Unit] > > Description=foo > > [Service] > > Type=oneshot > > ExecStart=/bin/sh -c "for i in `seq 1 200`; do echo $i; done" > > > > > > # systemctl start output.service > > # systemct status -n 100 > > log message 102-200 > > Nov 26 16:28:27 pluto systemd[1]: Started foo. > > You are demonstrating the good case, I am after a bad case. Let's try > this: > > [Unit] > Description=SomeThing > After=network.target > [Install] > WantedBy=multi-user.target > > [Service] > Type=notify > Restart=on-failure > ExecStart=/bin/sh -c "echo OMG THEY KILLED KENNY >&2; exit 123" > > and check the result: > > foo.service - SomeThing >Loaded: loaded (/lib/systemd/system/foo.service; disabled; vendor preset: > enabled) >Active: failed (Result: start-limit) since Sa 2015-11-28 11:28:39 CET; 13s > ago > Process: 6982 ExecStart=/bin/sh -c echo OMG THEY KILLED KENNY >&2; exit 123 > (code=exited, status=123) > Main PID: 6982 (code=exited, status=123) > > Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. > Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. > Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result > 'exit-code'. > Nov 28 11:28:39 idefix sh[6982]: OMG THEY KILLED KENNY > Nov 28 11:28:39 idefix systemd[1]: foo.service: Service hold-off time over, > scheduling restart. > Nov 28 11:28:39 idefix systemd[1]: Stopped SomeThing. > Nov 28 11:28:39 idefix systemd[1]: foo.service: Start request repeated too > quickly. > Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. > Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. > Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result > 'start-limit'. > > > Looks good, huh? So what is the major difference to the script in the > original report? > Is it maybe this? > Type=notify There's a race for short-lived programs - if the process has exited by the time journald looks the sender up in /proc, it will not be able to assign the message the right systemd unit. This means that the message will be in logs, but it will not be shown by 'systemctl status unit'/'journalctl -u unit'. This race is currently unfixable, until kernel provides additional functionality to attach more metadata to messages. So you should check with journalctl -u that the messages you think should be shown are really attached to that unit. > I can imagine that if the service dies before any dbus event was sent then the > messages are printed early, followed by the spam I mentioned? And that makes > them scroll out of "systemctl status" buffer? > > But anyhow, it's a secondary issue and probably deserves a second bug report. > The thing that botters me, see subject, is the broken -n option, adding -n20 > or > -n2000 to systemctl-status call does not change anything. It keeps displaying > 10 > lines. That's really strange. What is the exact command line that you are using? Does 'systemctl -n0 status ...' show any log lines? Do you have POSIXLY_CORRECT set? Zbyszek
Bug#806291: systemd: systemctl status ignores -n argument
Hallo, * Michael Biebl [Thu, Nov 26 2015, 04:32:43PM]: > Am 26.11.2015 um 15:59 schrieb Michael Biebl: > > Works here. But I actually need a service which produces more then 10 > > lines of output when started. > > To illustrate what I did: > > # cat /etc/systemd/system/output.service > [Unit] > Description=foo > [Service] > Type=oneshot > ExecStart=/bin/sh -c "for i in `seq 1 200`; do echo $i; done" > > > # systemctl start output.service > # systemct status -n 100 > log message 102-200 > Nov 26 16:28:27 pluto systemd[1]: Started foo. You are demonstrating the good case, I am after a bad case. Let's try this: [Unit] Description=SomeThing After=network.target [Install] WantedBy=multi-user.target [Service] Type=notify Restart=on-failure ExecStart=/bin/sh -c "echo OMG THEY KILLED KENNY >&2; exit 123" and check the result: foo.service - SomeThing Loaded: loaded (/lib/systemd/system/foo.service; disabled; vendor preset: enabled) Active: failed (Result: start-limit) since Sa 2015-11-28 11:28:39 CET; 13s ago Process: 6982 ExecStart=/bin/sh -c echo OMG THEY KILLED KENNY >&2; exit 123 (code=exited, status=123) Main PID: 6982 (code=exited, status=123) Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result 'exit-code'. Nov 28 11:28:39 idefix sh[6982]: OMG THEY KILLED KENNY Nov 28 11:28:39 idefix systemd[1]: foo.service: Service hold-off time over, scheduling restart. Nov 28 11:28:39 idefix systemd[1]: Stopped SomeThing. Nov 28 11:28:39 idefix systemd[1]: foo.service: Start request repeated too quickly. Nov 28 11:28:39 idefix systemd[1]: Failed to start SomeThing. Nov 28 11:28:39 idefix systemd[1]: foo.service: Unit entered failed state. Nov 28 11:28:39 idefix systemd[1]: foo.service: Failed with result 'start-limit'. Looks good, huh? So what is the major difference to the script in the original report? Is it maybe this? Type=notify I can imagine that if the service dies before any dbus event was sent then the messages are printed early, followed by the spam I mentioned? And that makes them scroll out of "systemctl status" buffer? But anyhow, it's a secondary issue and probably deserves a second bug report. The thing that botters me, see subject, is the broken -n option, adding -n20 or -n2000 to systemctl-status call does not change anything. It keeps displaying 10 lines. Regards, Eduard. -- lol, habe gerad eine spam mail bekommen mit: klicken sie hier um zu testen wie hoch ihr IQ ist... ich denke wenn ich raufklicke habe ich ihn nicht bestanden :))) signature.asc Description: PGP signature
Bug#806291: systemd: systemctl status ignores -n argument
Am 26.11.2015 um 15:59 schrieb Michael Biebl: > Works here. But I actually need a service which produces more then 10 > lines of output when started. To illustrate what I did: # cat /etc/systemd/system/output.service [Unit] Description=foo [Service] Type=oneshot ExecStart=/bin/sh -c "for i in `seq 1 200`; do echo $i; done" # systemctl start output.service # systemct status -n 100 log message 102-200 Nov 26 16:28:27 pluto systemd[1]: Started foo. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#806291: systemd: systemctl status ignores -n argument
Am 26.11.2015 um 08:00 schrieb Eduard Bloch: > Package: systemd > Version: 228-2 > > Dear Maintainer, > >* What led up to the situation? > > I created a buggy configuration of apt-cacher-ng and wondered why it did not > start. When I run the service from command line, it dumps a couple of usefull > hints to STDERR. I expected to see this in "systemctl status" output. I saw > only ten lines and this contained only useless cruft, something about > "hold-off time over" etc. > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > Since I expected useful information to be before this cruft, I used the > -n option as described in the systemctl manpage. -n 20, actually. > >* What was the outcome of this action? > > The same output was displayed. Only 10 lines with useless information. Feels > like -n ... value is simply ignored, I can set -n100 or -n1000, makes no > difference. > Works here. But I actually need a service which produces more then 10 lines of output when started. Remember that status only shows the logs from the most recent start/stop/restart attempt. I think it would be confusing if it showed output from, say the last boot. For that you need journalctl indeed. And if the daemon itself doesn't log to syslog or stdout, journald obviously doesn't catch that. So from what I can see, there is not really a bug here. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#806291: systemd: systemctl status ignores -n argument
Package: systemd Version: 228-2 Dear Maintainer, * What led up to the situation? I created a buggy configuration of apt-cacher-ng and wondered why it did not start. When I run the service from command line, it dumps a couple of usefull hints to STDERR. I expected to see this in "systemctl status" output. I saw only ten lines and this contained only useless cruft, something about "hold-off time over" etc. * What exactly did you do (or not do) that was effective (or ineffective)? Since I expected useful information to be before this cruft, I used the -n option as described in the systemctl manpage. -n 20, actually. * What was the outcome of this action? The same output was displayed. Only 10 lines with useless information. Feels like -n ... value is simply ignored, I can set -n100 or -n1000, makes no difference. % sudo systemctl status apt-cacher-ng.service -n 20 ● apt-cacher-ng.service - Apt-Cacher NG software download proxy Loaded: loaded (/lib/systemd/system/apt-cacher-ng.service; enabled; vendor preset: enabled) Active: failed (Result: start-limit) since Di 2015-11-24 22:04:02 CET; 1min 10s ago Process: 2842 ExecStart=/usr/sbin/apt-cacher-ng SocketPath=/var/run/apt-cacher-ng/socket -c /etc/apt-cacher-ng ForeGround=1 (code=exited, status=1/FAILURE) Main PID: 2842 (code=exited, status=1/FAILURE) Nov 24 22:04:02 idefix systemd[1]: Failed to start Apt-Cacher NG software download proxy. Nov 24 22:04:02 idefix systemd[1]: apt-cacher-ng.service: Unit entered failed state. Nov 24 22:04:02 idefix systemd[1]: apt-cacher-ng.service: Failed with result 'exit-code'. Nov 24 22:04:02 idefix systemd[1]: apt-cacher-ng.service: Service hold-off time over, scheduling restart. Nov 24 22:04:02 idefix systemd[1]: Stopped Apt-Cacher NG software download proxy. Nov 24 22:04:02 idefix systemd[1]: apt-cacher-ng.service: Start request repeated too quickly. Nov 24 22:04:02 idefix systemd[1]: Failed to start Apt-Cacher NG software download proxy. Nov 24 22:04:02 idefix systemd[1]: apt-cacher-ng.service: Unit entered failed state. Nov 24 22:04:02 idefix systemd[1]: apt-cacher-ng.service: Failed with result 'start-limit'. It also told me to use "journalctl -xn" alternatively but it doesn't show much more information either. * What outcome did you expect instead? USEFUL INFORMATION FROM THE DAEMON ITSELF! Not the logs of some process management of systemd which I don't care that much about. Eventually, I can find something valuable in "journalctl -b0" output that happened in the second before. This makes sense, but it's hard to find. Nov 24 22:04:01 idefix systemd[1]: Stopped Apt-Cacher NG software download proxy. Nov 24 22:04:01 idefix systemd[1]: Starting Apt-Cacher NG software download proxy... Nov 24 22:04:01 idefix apt-cacher-ng[2832]: WARNING: No configuration was read from file:backends_debvol Nov 24 22:04:01 idefix apt-cacher-ng[2832]: WARNING: No configuration was read from file:sfnet_mirrors Nov 24 22:04:01 idefix apt-cacher-ng[2832]: Warning, unknown configuration directive: OptProxyCheckCommand Nov 24 22:04:01 idefix apt-cacher-ng[2832]: Error reading main options, terminating. Nov 24 22:04:01 idefix systemd[1]: apt-cacher-ng.service: Main process exited, code=exited, status=1/FAILURE Nov 24 22:04:01 idefix systemd[1]: Failed to start Apt-Cacher NG software download proxy. Nov 24 22:04:01 idefix systemd[1]: apt-cacher-ng.service: Unit entered failed state. Nov 24 22:04:01 idefix systemd[1]: apt-cacher-ng.service: Failed with result 'exit-code'. Nov 24 22:04:01 idefix sudo[2825]: pam_unix(sudo:session): session closed for user root Nov 24 22:04:01 idefix polkitd(authority=local)[989]: Unregistered Authentication Agent for unix-process:2826:56921 (system bus name :1.56, object path /org/freedesktop/PolicyKit1/Authenticati Nov 24 22:04:01 idefix systemd[1]: apt-cacher-ng.service: Service hold-off time over, scheduling restart. Nov 24 22:04:01 idefix systemd[1]: Stopped Apt-Cacher NG software download proxy. Nov 24 22:04:01 idefix systemd[1]: Starting Apt-Cacher NG software download proxy... Nov 24 22:04:01 idefix apt-cacher-ng[2836]: WARNING: No configuration was read from file:backends_debvol Nov 24 22:04:01 idefix apt-cacher-ng[2836]: WARNING: No configuration was read from file:sfnet_mirrors Nov 24 22:04:01 idefix apt-cacher-ng[2836]: Warning, unknown configuration directive: OptProxyCheckCommand Nov 24 22:04:01 idefix apt-cacher-ng[2836]: Error reading main options, terminating. Nov 24 22:04:01 idefix systemd[1]: apt-cacher-ng.service: Main process exited, code=exited, status=1/FAILURE Nov 24 22:04:01 idefix systemd[1]: Failed to start Apt-Cacher NG software download proxy. Nov 24 22:04:01 idefix systemd[1]: apt-cacher-ng.service: Unit entered failed state. Nov 24 22:04:01 idefix systemd[1]: apt-cacher-ng.service: Failed with result 'exit-code'. Regards, Eduard. -- Package-specific info: -- System Information: Debian Release: stretch/sid
