Bug 696963

Please just install the upstream-maintained native systemd service files
named after the syslog implementation, and drop the multiplexing of all
possible syslog implementations through the magic SUSE sysconfig script on
systemd boots.

We need proper and unified native management of services, and which
implementation of syslog should be started is to be configured by:
systemctrl enable/disable, and not by magic multiplex switches in SUSE
config files, which we should avoid in the future for many reasons.

Syslog is special regarding SYSV compatibility. The current version of
systemd requires socket passing to be active for syslog to integrate with
systemd's only syslog logic, and will only work with native service files
and not with SYSV compat scripts.

Systemd also does not support any klogd-like process listening for kernel
messages and forwarding them to /dev/log. It will create a message loop
with the systemd's own kmsg bridge. The syslog implementation needs to
support reading kernel messages directly, to integrate properly with
systemd, or needs to explicitly work around such issues.

For 12.1, if we go with systemd we have to choose one of the syslog we have
syslog, syslog-ng, rsyslog 

which one is the best to use and to be push as default/recommanded ? 

Also there's a need in packaging to not force one of them but ask for capabilities. Example a plain factory use now rsyslog, if you ask for webyast you get syslog-ng

Until now I just see a regression in systemd that disallows LSB service
starts.

There is a feature request about improving the syslog / systemd issue:

  https://features.opensuse.org/311316

I guess, I'll not have time to work on this before August or something
like this.

BTW:
Using service file names named after the syslog daemon implementation
as described by Kay above (rsyslog.service, syslogd.service, ...)
needs a split out of every syslog-daemon into a <name>-systemd and
<name>-sysvinit to provide e.g. log rotation files with the correct
  systemctl action <name>.service
actions.
There will be no possibility any more to provide a custom config file
(/etc/rsyslog.d/foo-bar.conf) with log destination for a program and
a log rotation file without to follow the -systemd / -sysvinit split
because of the systemctl log rotation call that needs the implementation
name in the log rotation file.

IMO a step backward instead forward.

The limitation with klogd is AFAIR a systemd bug tracked already on 11.4.

(In reply to comment #2)

Most enterprise users want to have the choice between all three
sysloggers and the openSUSE is the base of all enterprise products.
Next is that systemd should not abuse the kernel kprintf logging
buffer but use its own logging ring buffer.

(In reply to comment #2)
> which one is the best to use and to be push as default/recommanded ? 

For now it's rsyslog, which is actively tested and supported from upstream.

> (In reply to comment #2)
> 
> Most enterprise users want to have the choice between all three
> sysloggers and the openSUSE is the base of all enterprise products.

Sure, if the syslog implementation supports systemd, it can be
enabled/disabled with systemctl commands. No magic needed here, it will
work just fine, like everything else on the system.

> Next is that systemd should not abuse the kernel kprintf logging
> buffer but use its own logging ring buffer.

"Abuse' is your personal opinion, which the systemd developers don't share.
We have quite to opposite feedback on this feature from many people involved
in this decision.

Early-boot messages are mixed with the kernel messages, in 'dmesg' and that's
exactly what you want to look at if things go wrong. These days it does not
matter at all if boot/init components run in user- or kernel-space, hence they
should log to the same target during early boot, until a real syslog is
available.

Laptop- and embedded-like setups do not need to run any syslog service at
all, but they still have a fully working 'syslog' from the kernel. It's just
that nothing is ever written to disk.

Rsyslog can distinguish the userspace messages from the kernel messages just
fine, and can even write them to different log files.

(In reply to comment #6)

With this approach you're not able to report all kernel and system messages
send to /dev/console to all console devices.  This is IMHO required for
all systems using e.g. a serial console together with an other console
e.g a virtual one or a simple printer.  OK most openSUSE nor Fedora users
will use this features but our enterprise customers do.

NB: I'm willingly to port the main features of blogd to systemd if and only
if this work is not for the waste basket of the upstream developers of
systemd.   Last month I've ported the main features of mingetty to agetty
of the current util-linux tree and Karel Zak has accepeted my patches. The
only question is due to my rare time for such a work (I'm currently hunting
bugs in the ksh93u and ksh93t) if such a contribution will be accepted or not.

(In reply to comment #7)
> (In reply to comment #6)
> 
> With this approach you're not able to report all kernel and system
> messages send to /dev/console to all console devices.  This is IMHO
> required for all systems using e.g. a serial console together with
> an other console

We should not try to make userspace 'smarter' than the kernel with
its log messages? We must avoid handling early-boot messages from
the kernel differently than the ones from early boot tools.

Today it is just an irrelevant detail if an early-boot tool runs
in kernel- or userspace. The only visible difference should be the
facility value of the syslog prefix.

I does not make much sense to have early-boot and kernel bootup-messages
separate. These messages belong together during the time the system is
brought up. The messages the kernel sends out need to show up the same
way, and on all the same devices.

So if there is anything missing, please let's change the kernel, and not
work around it in userspace without being able to provide a complete
solution to the problem.

Reassign to default. I have zero time to work on syslog issues. They need
to be fixed in the syslog package not in systemd.

I've no time do work on this.

Beside I'd like to see an real answer on my question in comment #8

(In reply to comment #9)

Our enterprise customers using serial consoles in combination with
virtual consoles (and there are a lot of customers) will not agree
with you're point of view.  It would be help a lot if you and/or
the upstream developer of systemd would not that snootily, that is
instead of ignoring requests from paying customers and the existing
solutions for such requests.

IMO this is not blocking adoption for openSUSE 12.1. For SLES 12 I expect that we need this, so after talking with mge, I created a feature for this, please help me to improve the feature.
It's 
https://features.opensuse.org/312466

Btw. I'm submitting a rsyslog with native systemd service file again to factory now.

This is an autogenerated message for OBS integration:
This bug (696963) was mentioned in
https://build.opensuse.org/request/show/72365 Factory / rsyslog

fixed

This is an autogenerated message for OBS integration:
This bug (696963) was mentioned in
https://build.opensuse.org/request/show/672696 15.1 / syslog-ng