[opensuse-factory] systemd integration
Hey, here is a list of things that still need to be done, or need to be discussed how to be done. Note: there is a wiki page about this: http://en.opensuse.org/openSUSE:Systemd_status And for any non-SUSE-specific bugs or requests, please use the upstream mailing list and bug tracker, not this list or the SUSE bugtracker. - systemd service files - a bunch of services need native systemd service files to replace the SYSV init script - some just need to be enabled in the build with: --with-systemdsystemunitdir=/lib/systemd/system - some needs to be packaged and taken from the Fedora packages - some needs to written - systemd/SYSV service management - the init scripts should call systemd if systemd is used, e.g. /etc/init.d/cups start" should either print a warning or call "systemctl start cups.service" directly - Fedora's systemd calls 'chkconfig' for SYSV scripts, so all services can be managed with 'systemctl'. - the YaST2 runlevel editor needs to be modified for systemd, the API of the runlevel editor is used by other YaST modules to enable/disable/query services - RPM package upgrade and systemd service files - systemd services should be enabled only the first time a systemd service files is shipped, depending on the current state of the sysv service. - systemd services are currently only enabled when the package is installed the first time, not with an update. - some SUSE packages ship systemd files, but don't enable the systemd service - replace SUSE-specific config files to new cross-distro configs: /etc/os-release (like /etc/SuSE-release) /etc/locale (replaces /etc/sysconfig/language) /etc/tmpfiles.d/ (replaces /etc/tmpdirs.d/) /etc/vconsole.conf (replaces /etc/sysconfig/keyboard,console) /etc/modules-load.d/ (replaces /etc/sysconfig/kernel::MODULES_LOADED ...) - some of the old SUSE-specific config files are read by systemd, but we should start using the new "Linux default" - splash integration - systemd supports only plymouth at the moment, possibly just switch to plymouth? - move X to tty1 - to avoid VT switch on bootup - to match systemd's getty1 logic - future systemd will support on-demand getty (getty2-6 are only started on VT switch) - getty1/X will be special, depending which "runlevel" is used - sort out the /etc/init.d/xdm config mess (how to convert that beast to a _proper_ systemd service?) - sort out the mess in /etc/init.d/syslog - probably just provide native service file for rsyslog, and disable the this weird script - systemd wants a syslog with socket activation, upstream rsyslog supports this already - sort out NetworkManager vs. sysconfig mess - starting NetworkManager from a the sysconfig init script, depending on a config variable is just weird - on Fedora NM can always be started and just leaves interfaces alone, that are configured in the "old scripts", all unconfigured interfaces are managed by NM. That way, NM can always run, without interfering with static config, or it just be entirely disabled with its own initscript/systemd service. - YaST2 2nd stage/first boot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 25 Nov 2010 08:27:45 +0100 Kay Sievers <kay.sievers@vrfy.org> wrote:
Hey, here is a list of things that still need to be done, or need to be discussed how to be done.
Note: there is a wiki page about this: http://en.opensuse.org/openSUSE:Systemd_status
And for any non-SUSE-specific bugs or requests, please use the upstream mailing list and bug tracker, not this list or the SUSE bugtracker.
- systemd/SYSV service management - the init scripts should call systemd if systemd is used, e.g. /etc/init.d/cups start" should either print a warning or call "systemctl start cups.service" directly
Is there a cheap way to find out if systemd is used? An environment variable probably?
- Fedora's systemd calls 'chkconfig' for SYSV scripts, so all services can be managed with 'systemctl'.
I don't get the connection between chkconfig and "services can be manages with systemctl", or, in other words: -vvv please :-)
- some of the old SUSE-specific config files are read by systemd, but we should start using the new "Linux default"
This is surely already in some draft of LSB, or do we have to change this 3 months from now, again?
- sort out NetworkManager vs. sysconfig mess - starting NetworkManager from a the sysconfig init script, depending on a config variable is just weird - on Fedora NM can always be started and just leaves interfaces alone, that are configured in the "old scripts", all unconfigured interfaces are managed by NM. That way, NM can always run, without interfering with static config, or it just be entirely disabled with its own initscript/systemd service.
sounds like a viable approach to me. One thing from the Wiki page: * bluez-coldplug This is just a workaround to replay the bluez udev events once dbus is up (bluetoothd itself is started by dbus activation), so it probably is not needed at all with systemd. I'll try disabling it here and will check with next kernel update if bluetooth still works :-) -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 2010-11-25 at 09:52 +0100, Stefan Seyfried wrote:
On Thu, 25 Nov 2010 08:27:45 +0100 Kay Sievers <kay.sievers@vrfy.org> wrote:
- systemd/SYSV service management - the init scripts should call systemd if systemd is used, e.g. /etc/init.d/cups start" should either print a warning or call "systemctl start cups.service" directly
Is there a cheap way to find out if systemd is used? An environment variable probably?
The existence of /sys/fs/cgroup/systemd/ is usually used.
- Fedora's systemd calls 'chkconfig' for SYSV scripts, so all services can be managed with 'systemctl'.
I don't get the connection between chkconfig and "services can be manages with systemctl", or, in other words: -vvv please :-)
I case you have only: /etc/init.d/foo but no: /lib/systemd/system/foo.service you can still do: systemctl start foo.service
- some of the old SUSE-specific config files are read by systemd, but we should start using the new "Linux default"
This is surely already in some draft of LSB, or do we have to change this 3 months from now, again?
No, it was decided not to care about the shell script mess LSB likes to establish: a script to parse a simple config file. It just does not make much sense what they already have. If all the new cross-distro config works out, it will be proposed to LSB. What they will do with in after many years, nobody knows. :)
- sort out NetworkManager vs. sysconfig mess - starting NetworkManager from a the sysconfig init script, depending on a config variable is just weird - on Fedora NM can always be started and just leaves interfaces alone, that are configured in the "old scripts", all unconfigured interfaces are managed by NM. That way, NM can always run, without interfering with static config, or it just be entirely disabled with its own initscript/systemd service.
sounds like a viable approach to me.
Yeah, that's something that makes at least a bit of sense, in contrast to what we do now.
One thing from the Wiki page: * bluez-coldplug This is just a workaround to replay the bluez udev events once dbus is up (bluetoothd itself is started by dbus activation), so it probably is not needed at all with systemd. I'll try disabling it here and will check with next kernel update if bluetooth still works :-)
It should just flow-in from upstream, that's why it's not listed in this mail, which is mostly about SUSE issues. Here is the patch: http://www.spinics.net/lists/linux-bluetooth/msg08554.html Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 2010/11/25 08:27 (GMT+0100) Kay Sievers composed:
Note: there is a wiki page about this: http://en.opensuse.org/openSUSE:Systemd_status
The rationale to use it seems to be missing.
- splash integration - systemd supports only plymouth at the moment, possibly just switch to plymouth?
Splash eradication needs to be easier than it is in Fedora, with its excessive/illogical deps.
- move X to tty1 - to avoid VT switch on bootup - to match systemd's getty1 logic - future systemd will support on-demand getty (getty2-6 are only started on VT switch) - getty1/X will be special, depending which "runlevel" is used
The boot messages are on tty1. Will they be moved elsewhere so as not to be cleared when X actually starts? This is a misfeature in Fedora. -- "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 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 25 Nov 2010 05:22:36 -0500 Felix Miata <mrmazda@earthlink.net> wrote:
On 2010/11/25 08:27 (GMT+0100) Kay Sievers composed:
Note: there is a wiki page about this: http://en.opensuse.org/openSUSE:Systemd_status
The rationale to use it seems to be missing.
That's a status page
- move X to tty1 - to avoid VT switch on bootup - to match systemd's getty1 logic - future systemd will support on-demand getty (getty2-6 are only started on VT switch) - getty1/X will be special, depending which "runlevel" is used
The boot messages are on tty1. Will they be moved elsewhere so as not to be cleared when X actually starts? This is a misfeature in Fedora.
With systemd, there are no boot messages anymore (besides the few lines the kernel prints. And actually, even though I was opposed to that in the beginning, now I find the output of systemctl much more useful to find out what was started and what failed than the randomly intermixed boot messages. And only the last few lines were preserved anyway. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 2010/11/25 13:30 (GMT+0100) Stefan Seyfried composed:
Felix Miata wrote:
The boot messages are on tty1. Will they be moved elsewhere so as not to be cleared when X actually starts? This is a misfeature in Fedora.
With systemd, there are no boot messages anymore (besides the few lines the kernel prints. And actually, even though I was opposed to that in the beginning, now I find the output of systemctl much more useful to find out what was started and what failed than the randomly intermixed boot messages. And only the last few lines were preserved anyway.
Can the output of systemctl or systemd be configured to automatically display as highly legible framebuffer text that serves as an indication that something is actually happening, and instant warning of impending failure when e.g. can't find root or eth0 gets no IP assignment? These are among my favorite reasons to not use Windows, and to remove bootsplash from Linux ASAP after installation completes. -- "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 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 2010-11-25 at 09:03 -0500, Felix Miata wrote:
On 2010/11/25 13:30 (GMT+0100) Stefan Seyfried composed:
Felix Miata wrote:
The boot messages are on tty1. Will they be moved elsewhere so as not to be cleared when X actually starts? This is a misfeature in Fedora.
With systemd, there are no boot messages anymore (besides the few lines the kernel prints. And actually, even though I was opposed to that in the beginning, now I find the output of systemctl much more useful to find out what was started and what failed than the randomly intermixed boot messages. And only the last few lines were preserved anyway.
Can the output of systemctl or systemd be configured to automatically display as highly legible framebuffer text that serves as an indication that something is actually happening, and instant warning of impending failure when e.g. can't find root or eth0 gets no IP assignment?
Just remove 'quiet' from the kernel commandline. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2010-11-25 at 15:06 +0100, Kay Sievers wrote:
Can the output of systemctl or systemd be configured to automatically display as highly legible framebuffer text that serves as an indication that something is actually happening, and instant warning of impending failure when e.g. can't find root or eth0 gets no IP assignment?
Just remove 'quiet' from the kernel commandline.
But if X goes to tty1, they will be removed. How can they bee seen, now? - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkz2TJ0ACgkQtTMYHG2NR9WgfwCeMc2wcfFSSPPiLSOnxBNdik5L IoEAn2yLt6RTqoYcghfeenGljeKkT2rS =zSSY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Kay Sievers wrote:
- systemd/SYSV service management - the init scripts should call systemd if systemd is used, e.g. /etc/init.d/cups start" should either print a warning or call "systemctl start cups.service" directly
I'd suggest to turn the {/usr,}/sbin/rcfoo -> /etc/init/foo symlinks to links to /sbin/service. That script can then decide whether to talk to systemd or run the initscript. The conversion could be done automatically via brp script.
- replace SUSE-specific config files to new cross-distro configs: /etc/os-release (like /etc/SuSE-release)
Why not call it /etc/linux? :-)
- some of the old SUSE-specific config files are read by systemd, but we should start using the new "Linux default"
Ah, that reveals the real intentions.
- sort out NetworkManager vs. sysconfig mess - starting NetworkManager from a the sysconfig init script, depending on a config variable is just weird
Isn't that just the logical consequence of the usual freedesktop.org "There can be only one" philosophy we see a lot nowadays? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 2010-11-25 at 11:23 +0100, Ludwig Nussel wrote:
Kay Sievers wrote:
- systemd/SYSV service management - the init scripts should call systemd if systemd is used, e.g. /etc/init.d/cups start" should either print a warning or call "systemctl start cups.service" directly
I'd suggest to turn the {/usr,}/sbin/rcfoo -> /etc/init/foo symlinks to links to /sbin/service. That script can then decide whether to talk to systemd or run the initscript. The conversion could be done automatically via brp script.
Lots of things don't do the rcfoo stuff, just /etc/init.d/foo, right? Other distros are doing it by adding stuff to /etc/rc.status, which is sourced-in by every file.
- replace SUSE-specific config files to new cross-distro configs: /etc/os-release (like /etc/SuSE-release)
Why not call it /etc/linux? :-)
Yeah, no reason. :)
- some of the old SUSE-specific config files are read by systemd, but we should start using the new "Linux default"
Ah, that reveals the real intentions.
- sort out NetworkManager vs. sysconfig mess - starting NetworkManager from a the sysconfig init script, depending on a config variable is just weird
Isn't that just the logical consequence of the usual freedesktop.org "There can be only one" philosophy we see a lot nowadays?
Why? NM on Fedora works fine running at the same time as the old network scripts stuff. If there is an old config, NM ignores the device/ I think that's much better than what we do. And it allows us to have proper D-Bus activation of NM, to be able to ignore dependencies, and NM service files to manage if NM is used. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag, 25. November 2010, 12:29:29 schrieb Kay Sievers:
- sort out NetworkManager vs. sysconfig mess
- starting NetworkManager from a the sysconfig init script,
depending on a config variable is just weird
Isn't that just the logical consequence of the usual freedesktop.org "There can be only one" philosophy we see a lot nowadays?
Why? NM on Fedora works fine running at the same time as the old network scripts stuff. If there is an old config, NM ignores the device/ I think that's much better than what we do.
And it allows us to have proper D-Bus activation of NM, to be able to ignore dependencies, and NM service files to manage if NM is used.
NetworkManager has a ton of dependencies that some people might not want, do we really need to force install them to run a basicly idle process? My debian server is fine with a static connection and fits on a small sd card, I guess it can't hurt to support that usecase in opensuse. Cheers, Karsten -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 2010-11-25 at 12:38 +0100, Karsten König wrote:
Am Donnerstag, 25. November 2010, 12:29:29 schrieb Kay Sievers:
- sort out NetworkManager vs. sysconfig mess
- starting NetworkManager from a the sysconfig init script,
depending on a config variable is just weird
Isn't that just the logical consequence of the usual freedesktop.org "There can be only one" philosophy we see a lot nowadays?
Why? NM on Fedora works fine running at the same time as the old network scripts stuff. If there is an old config, NM ignores the device/ I think that's much better than what we do.
And it allows us to have proper D-Bus activation of NM, to be able to ignore dependencies, and NM service files to manage if NM is used.
NetworkManager has a ton of dependencies that some people might not want, do we really need to force install them to run a basicly idle process? My debian server is fine with a static connection and fits on a small sd card, I guess it can't hurt to support that usecase in opensuse.
Force? This is about how NM is used *when* it's used, nothing else. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag, 25. November 2010, 12:41:36 schrieb Kay Sievers:
On Thu, 2010-11-25 at 12:38 +0100, Karsten König wrote:
Am Donnerstag, 25. November 2010, 12:29:29 schrieb Kay Sievers:
- sort out NetworkManager vs. sysconfig mess
- starting NetworkManager from a the sysconfig init script,
depending on a config variable is just weird
Isn't that just the logical consequence of the usual freedesktop.org "There can be only one" philosophy we see a lot nowadays?
Why? NM on Fedora works fine running at the same time as the old network scripts stuff. If there is an old config, NM ignores the device/ I think that's much better than what we do.
And it allows us to have proper D-Bus activation of NM, to be able to ignore dependencies, and NM service files to manage if NM is used.
NetworkManager has a ton of dependencies that some people might not want, do we really need to force install them to run a basicly idle process? My debian server is fine with a static connection and fits on a small sd card, I guess it can't hurt to support that usecase in opensuse.
Force? This is about how NM is used *when* it's used, nothing else.
Oh sorry, I was under the impression NM gets installed if you want network =) Cheers, Karsten -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Kay Sievers wrote:
On Thu, 2010-11-25 at 11:23 +0100, Ludwig Nussel wrote:
Kay Sievers wrote:
- sort out NetworkManager vs. sysconfig mess - starting NetworkManager from a the sysconfig init script, depending on a config variable is just weird
Isn't that just the logical consequence of the usual freedesktop.org "There can be only one" philosophy we see a lot nowadays?
Why? NM on Fedora works fine running at the same time as the old network scripts stuff. If there is an old config, NM ignores the device/ I think that's much better than what we do.
No idea. It probably was the lesser evil as two systems trying to manage e.g. the default route don't play together well. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 2010-11-25 at 14:25 +0100, Ludwig Nussel wrote:
Kay Sievers wrote:
On Thu, 2010-11-25 at 11:23 +0100, Ludwig Nussel wrote:
Kay Sievers wrote:
- sort out NetworkManager vs. sysconfig mess - starting NetworkManager from a the sysconfig init script, depending on a config variable is just weird
Isn't that just the logical consequence of the usual freedesktop.org "There can be only one" philosophy we see a lot nowadays?
Why? NM on Fedora works fine running at the same time as the old network scripts stuff. If there is an old config, NM ignores the device/ I think that's much better than what we do.
No idea. It probably was the lesser evil as two systems trying to manage e.g. the default route don't play together well.
It could probably just use multiple default routes with metrics. Being able to have both at the same time still sounds interesting for quite a few setups. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Kay Sievers wrote: Hi,
- sort out the mess in /etc/init.d/syslog - probably just provide native service file for rsyslog, and disable the this weird script - systemd wants a syslog with socket activation, upstream rsyslog supports this already
Is syslog-ng support planned, too? I find the possibility to select a syslog daemon of my choice extremely helpful and it would be sad to be reduced to rsyslog only. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2010-11-26 at 12:04 +0100, Joachim Schrod wrote:
Kay Sievers wrote:
- sort out the mess in /etc/init.d/syslog - probably just provide native service file for rsyslog, and disable the this weird script - systemd wants a syslog with socket activation, upstream rsyslog supports this already
Is syslog-ng support planned, too?
I find the possibility to select a syslog daemon of my choice extremely helpful and it would be sad to be reduced to rsyslog only.
Somebody needs to patch it, to accept socket activation, and write service files for it. Without that, it's not properly supported. http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=41327992680cfb8dd602ea9... http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=8e51241a50531dc10d00e54... Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 2010-11-26 12:36:31 +0100, Kay Sievers wrote:
On Fri, 2010-11-26 at 12:04 +0100, Joachim Schrod wrote:
Kay Sievers wrote:
- sort out the mess in /etc/init.d/syslog - probably just provide native service file for rsyslog, and disable the this weird script - systemd wants a syslog with socket activation, upstream rsyslog supports this already
Is syslog-ng support planned, too?
I find the possibility to select a syslog daemon of my choice extremely helpful and it would be sad to be reduced to rsyslog only.
Somebody needs to patch it, to accept socket activation, and write service files for it. Without that, it's not properly supported.
so does that mean that every service that doesnt have socket activation stuff will not be properly supported? i can imagine enough services where you dont want the delayed starts and all that. the only feature, that i really miss in SysV init atm, is service supervision. but one can easily get that with runit. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2010-11-26 at 13:43 +0100, Marcus Rueckert wrote:
On 2010-11-26 12:36:31 +0100, Kay Sievers wrote:
On Fri, 2010-11-26 at 12:04 +0100, Joachim Schrod wrote:
Kay Sievers wrote:
- sort out the mess in /etc/init.d/syslog - probably just provide native service file for rsyslog, and disable the this weird script - systemd wants a syslog with socket activation, upstream rsyslog supports this already
Is syslog-ng support planned, too?
I find the possibility to select a syslog daemon of my choice extremely helpful and it would be sad to be reduced to rsyslog only.
Somebody needs to patch it, to accept socket activation, and write service files for it. Without that, it's not properly supported.
so does that mean that every service that doesnt have socket activation stuff will not be properly supported? i can imagine enough services where you dont want the delayed starts and all that.
No, syslog is very special in that context, like udev or D-Bus are special for systemd. Systemd needs to race-free pass over its own /dev/log socket that connects to the kernel buffer, hence the requirement for syslog. With that infrastructure, you can even replace any running syslog, even with a different product, any time, without ever losing a single message. But it needs to support systemd's socket activation. Most other stuff is just a normal service. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Nov 26, 2010 at 01:54:07PM +0100, Kay Sievers wrote:
On Fri, 2010-11-26 at 13:43 +0100, Marcus Rueckert wrote:
so does that mean that every service that doesnt have socket activation stuff will not be properly supported? i can imagine enough services where you dont want the delayed starts and all that.
No, syslog is very special in that context, like udev or D-Bus are special for systemd.
Systemd needs to race-free pass over its own /dev/log socket that connects to the kernel buffer, hence the requirement for syslog.
With that infrastructure, you can even replace any running syslog, even with a different product, any time, without ever losing a single message. But it needs to support systemd's socket activation.
Most other stuff is just a normal service.
Then ...please... open a bugzilla, and then we add the required patches to all three syslog deamons. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Freitag, 26. November 2010 14:43:54 schrieb Dr. Werner Fink:
On Fri, Nov 26, 2010 at 01:54:07PM +0100, Kay Sievers wrote:
On Fri, 2010-11-26 at 13:43 +0100, Marcus Rueckert wrote:
so does that mean that every service that doesnt have socket activation stuff will not be properly supported? i can imagine enough services where you dont want the delayed starts and all that.
No, syslog is very special in that context, like udev or D-Bus are special for systemd.
Systemd needs to race-free pass over its own /dev/log socket that connects to the kernel buffer, hence the requirement for syslog.
With that infrastructure, you can even replace any running syslog, even with a different product, any time, without ever losing a single message. But it needs to support systemd's socket activation.
Most other stuff is just a normal service.
Then ...please... open a bugzilla, and then we add the required patches to all three syslog deamons.
I've opened one: https://bugzilla.novell.com/show_bug.cgi?id=656104 Gruesse / Regards, Marius Tomaschewski <mt@suse.de> <mt@novell.com> -- Server Technologies Team, SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex; HRB 16746 (AG Nuernberg) GPG/PGP public key fingerprint: DF17 271A AD15 006A 5BB9 6C96 CA2F F3F7 373A 1CC0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Freitag, 26. November 2010 12:04:46 schrieb Joachim Schrod:
Kay Sievers wrote:
Hi,
- sort out the mess in /etc/init.d/syslog - probably just provide native service file for rsyslog, and disable the this weird script - systemd wants a syslog with socket activation, upstream rsyslog supports this already
Is syslog-ng support planned, too?
I find the possibility to select a syslog daemon of my choice extremely helpful and it would be sad to be reduced to rsyslog only.
Don't worry. We will keep the choice and implement it for syslog-ng and syslogd as well. Looking at the patches in rsyslog, it is quite straight forward to do it. See also: https://bugzilla.novell.com/show_bug.cgi?id=656104 Gruesse / Regards, Marius Tomaschewski <mt@suse.de> <mt@novell.com> -- Server Technologies Team, SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex; HRB 16746 (AG Nuernberg) GPG/PGP public key fingerprint: DF17 271A AD15 006A 5BB9 6C96 CA2F F3F7 373A 1CC0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On 11/26/2010 03:02 PM, Marius Tomaschewski wrote:
Am Freitag, 26. November 2010 12:04:46 schrieb Joachim Schrod:
Kay Sievers wrote:
Hi,
- sort out the mess in /etc/init.d/syslog - probably just provide native service file for rsyslog, and disable the this weird script - systemd wants a syslog with socket activation, upstream rsyslog supports this already
Is syslog-ng support planned, too?
I find the possibility to select a syslog daemon of my choice extremely helpful and it would be sad to be reduced to rsyslog only.
Don't worry.
We will keep the choice and implement it for syslog-ng and syslogd as well. Looking at the patches in rsyslog, it is quite straight forward to do it.
May I ask you to implent it for syslog-ng 3.2? That's what I'd like to push into openSUSE 11.4 next week, and 3.1 is feature frozen upstream anyway. A package from 3.2 beta1 is available at https://build.opensuse.org/package/show?package=syslog-ng32&project=home%3Aczanik%3Asyslog-ng32 It currently fails to compile due to libnet changes. I'll fix that and update to latest git (which should not change much until the 3.2 release...) Bye, -- Peter Czanik (CzP) <czanik@balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Freitag, 26. November 2010 17:17:26 schrieb Peter Czanik:
Hello, Hello!
May I ask you to implent it for syslog-ng 3.2?
When nothing urgent comes beween, yes - next week I think. Gruesse / Regards, Marius Tomaschewski <mt@suse.de> <mt@novell.com> -- Server Technologies Team, SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex; HRB 16746 (AG Nuernberg) GPG/PGP public key fingerprint: DF17 271A AD15 006A 5BB9 6C96 CA2F F3F7 373A 1CC0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 11/26/2010 09:08 PM, Marius Tomaschewski wrote:
Am Freitag, 26. November 2010 17:17:26 schrieb Peter Czanik:
Hello,
Hello!
May I ask you to implent it for syslog-ng 3.2?
When nothing urgent comes beween, yes - next week I think.
Thanks. My latest 3.2 package is available at https://build.opensuse.org/package/show?package=syslog-ng32&project=home%3Aczanik%3Asyslog-ng32 It is still waiting for a compile on the Build Service, but it built fine locally, and I use it currently. I tested it on 11.3, as factory vmware is now broken, and installing it new did not work either... Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (12)
-
Carlos E. R. -
Dr. Werner Fink -
Felix Miata -
Joachim Schrod -
Karsten König -
Kay Sievers -
Kay Sievers -
Ludwig Nussel -
Marcus Rueckert -
Marius Tomaschewski -
Peter Czanik -
Stefan Seyfried