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.
--
<meebey> lol, habe gerad eine spam mail bekommen mit: klicken sie hier
um zu testen wie hoch ihr IQ ist...
<meebey> ich denke wenn ich raufklicke habe ich ihn nicht bestanden :)))
signature.asc
Description: PGP signature
