Bug#806291: systemd: systemctl status ignores -n argument

[Eduard Bloch]

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 :)))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20151128/69e9d748/attachment-0002.sig>