Through 13.1 there were always messages on tty10, very rarely any on whichever if tty[1-6] was/were in use. Post-13.1 it seems there is no way to get them back that doesn't litter whichever tty is logged in on and active. I've tried various combinations of ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole= & ForwardToWall= from the journald.conf man page, but whatever I try, I get either nothing on tty10, or what's expected on tty10 plus complete trashing of whatever tty I'm trying to use. The litter seems to have escalated since systemd-2.19 found its way into TW. What incantations are required to recover the old behavior?
On Wed, Apr 22, 2015 at 11:25 AM, Felix Miata mrmazda@earthlink.net wrote:
Through 13.1 there were always messages on tty10, very rarely any on whichever if tty[1-6] was/were in use. Post-13.1 it seems there is no way to get them back that doesn't litter whichever tty is logged in on and active. I've tried various combinations of ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole= & ForwardToWall= from the journald.conf man page, but whatever I try, I get either nothing on tty10, or what's expected on tty10 plus complete trashing of whatever tty I'm trying to use.
Did you try TTYPath=?
The litter seems tohave escalated since systemd-2.19 found its way into TW. What incantations are required to recover the old behavior? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2015-04-22 11:35 (UTC+0300):
Felix Miata wrote:
Through 13.1 there were always messages on tty10, very rarely any on whichever if tty[1-6] was/were in use. Post-13.1 it seems there is no way to get them back that doesn't litter whichever tty is logged in on and active. I've tried various combinations of ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole= & ForwardToWall= from the journald.conf man page, but whatever I try, I get either nothing on tty10, or what's expected on tty10 plus complete trashing of whatever tty I'm trying to use.
Did you try TTYPath=?
In every combination tried I have had
TTYPath=/dev/tty10
uncommented.
If only that line is uncommented, simply logging on tty3 in results in 10 audit/PAM messages spit out before Have a lot of fun... on just dup'd TW, none of which show up on tty10, where last message of 10 lines in total is a 10th systemd-fsck... line.
The litter seems to
have escalated since systemd-2.19 found its way into TW. What incantations are required to recover the old behavior?
В Wed, 22 Apr 2015 04:49:53 -0400 Felix Miata mrmazda@earthlink.net пишет:
Andrei Borzenkov composed on 2015-04-22 11:35 (UTC+0300):
Felix Miata wrote:
Through 13.1 there were always messages on tty10, very rarely any on whichever if tty[1-6] was/were in use. Post-13.1 it seems there is no way to get them back that doesn't litter whichever tty is logged in on and active. I've tried various combinations of ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole= & ForwardToWall= from the journald.conf man page, but whatever I try, I get either nothing on tty10, or what's expected on tty10 plus complete trashing of whatever tty I'm trying to use.
Did you try TTYPath=?
In every combination tried I have had
TTYPath=/dev/tty10
uncommented.
If only that line is uncommented, simply logging on tty3 in results in 10 audit/PAM messages spit out before Have a lot of fun... on just dup'd TW, none of which show up on tty10, where last message of 10 lines in total is a 10th systemd-fsck... line.
Using default TW installation after setting
ForwardToConsole=yes
I get quite a lot of messages on tty10 - except kernel ones. If you get audit messages on active console, you most likely removed "quiet" from kernel command line. kernel writes messages to active console and has always been doing it; nothing has changed. In the past console log level was often set to suppress them somewhere in startup scripts (dmesg -n or similar); today using "quiet" by default effectively does the same.
systemd will not forward kernel messages anywhere except storing them in journal. Dispatching them to console looks relatively straightforward; I suppose that is something that has good chances to be accepted in openSUSE (it would complement existing compatibility patches). It should not be hard to implement (it is effectively just a single line).
The litter seems tohave escalated since systemd-2.19 found its way into TW. What incantations are required to recover the old behavior?
Please explain how kernel behavior is related to systemd. Anyway, I do not see any litter in default installation; so may be try to revert your changes until you find what causes it?
Andrei Borzenkov composed on 2015-04-23 21:38 (UTC+0300):
Wed, 22 Apr 2015 04:49:53 -0400 Felix Miata composed:
In every combination tried I have had
TTYPath=/dev/tty10
uncommented.
If only that line is uncommented, simply logging on tty3 in results in 10 audit/PAM messages spit out before Have a lot of fun... on just dup'd TW,
Installing missing audit package seems to have solved this. Since installing, the only messages I've not "expected" happened during zypper -v dup.
none of which show up on tty10, where last message of 10 lines in total is a 10th systemd-fsck... line.
Using default TW installation after setting
ForwardToConsole=yes
I get quite a lot of messages on tty10 - except kernel ones. If you get audit messages on active console, you most likely removed "quiet" from kernel command line.
Can't remove what was never there to start with. As the installation choices are limited to Grub2 and none, TW gets installed here sans bootloader, and boot is via a copy and edit of one of the previous decade's working stanzas that have it not, living on a partition TW does not depend on for its functionality.
kernel writes messages to active console and has always been doing it; nothing has changed.
NAICT, quiet only affects default tty and only during init....
In the past console log level was often set to suppress them somewhere in startup scripts (dmesg -n or similar); today using "quiet" by default effectively does the same.
....I tried it once minutes ago. It results in nothing but black on screen between initrd loading and initial shell prompt.
This thread seems to be primarily about audit rpm not being required by anything. http://bugzilla.opensuse.org/show_bug.cgi?id=860778 has more to say.
Felix Miata wrote:
Through 13.1 there were always messages on tty10, very rarely any on whichever if tty[1-6] was/were in use. Post-13.1 it seems there is no way to get them back that doesn't litter whichever tty is logged in on and active.
klogd is diabled by default. If you enable it, I think you'll get the behaviour you expect.
Per Jessen composed on 2015-04-22 10:48 (UTC+0200):
Felix Miata wrote:
Through 13.1 there were always messages on tty10, very rarely any on whichever if tty[1-6] was/were in use. Post-13.1 it seems there is no way to get them back that doesn't litter whichever tty is logged in on and active.
klogd is diabled by default. If you enable it, I think you'll get the behaviour you expect.
Enabling klogd does not seem to have caused any improvement. Still nothing is showing up post-boot on tty10. Still the active tty and tty1 are heavily littered.
â klogd.service - System Kernel Logging Service Loaded: loaded (/usr/lib/systemd/system/klogd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2015-04-22 05:41:13 EDT; 2min 21s ago Process: 788 ExecStart=/sbin/klogd -c $KERNEL_LOGLEVEL $KLOGD_PARAMS -x (code=exited, status=0/SUCCESS) Main PID: 792 (code=exited, status=1/FAILURE)
Apr 22 05:41:12 m7ncd systemd[1]: Starting System Kernel Logging Service... Apr 22 05:41:13 m7ncd systemd[1]: Started System Kernel Logging Service. Apr 22 05:41:13 m7ncd systemd[1]: Unit klogd.service is bound to inactive unit. Stopping, too. Apr 22 05:41:13 m7ncd systemd[1]: Stopping System Kernel Logging Service... Apr 22 05:41:13 m7ncd systemd[1]: klogd.service: main process exited, code=exited, status=1/FAILURE Apr 22 05:41:13 m7ncd systemd[1]: Stopped System Kernel Logging Service. Apr 22 05:41:13 m7ncd systemd[1]: Unit klogd.service entered failed state. Apr 22 05:41:13 m7ncd systemd[1]: klogd.service failed.
-
Andrei Borzenkov -
Felix Miata -
Per Jessen