https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c1 Marius Tomaschewski changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |coolo@novell.com --- Comment #1 from Marius Tomaschewski 2010-11-29 13:17:25 UTC --- This is *bad* and IMO should be fixed ASAP. Everywhere a different clone of the sd-daemon.[ch] are used. The files are available in the systemd package: OBS/Base:System/systemd $ rpm -qlp systemd-15-55.1.x86_64.rpm | grep sd-daemon /usr/share/doc/packages/systemd/sd-daemon.c /usr/share/doc/packages/systemd/sd-daemon.h /usr/share/man/man7/sd-daemon.7.gz Now, I've to update the rsyslog files and add the patch to syslog-ng and this means I've to create clone of the files again. I don't think this is acceptable situation - I've more important things to do than to monitor systemd changes. Please build a devel package. Stephan, would you assign importance for this bug to unify this, please? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c3 --- Comment #3 from Kay Sievers 2010-11-29 14:40:11 UTC --- Note: In case you don't like to include the current convenience files, just use getenv("LISTEN_FDS") -- the needed functionality is not really much more than this. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c5 --- Comment #5 from Marius Tomaschewski 2010-11-29 15:15:59 UTC --- (In reply to comment #3)

Note: In case you don't like to include the current convenience files, just use getenv("LISTEN_FDS") -- the needed functionality is not really much more than this.

What you propose is to _reimplement_ all what the library in question is doing: The lib _is_ using getenv("LISTEN_FDS") + tons of checks, that I've to implement then. No, thanks! You just need to extract the recent Makefile.am changes from git master that build the library already and change from "noinst_" to "lib_" to install the library -- everything needed there. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c7 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|coolo@novell.com | --- Comment #7 from Stephan Kulow 2011-01-11 12:12:50 CET --- Not having a stable API sounds like a good reason not to adapt our daemons ;( -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c8 --- Comment #8 from Marius Tomaschewski 2011-02-10 15:35:34 UTC --- Kay, I know you've a good connection to systemd upstream, so I ask you :-) As you can see in bug 656104 comment 21, we've added support to forward the sockets to a child process to startproc and to fork code in all syslog daemons [syslogd, rsyslog, syslog-ng] too, so the socket activation works in Type=forking mode. Could you try to get this function upstream? : static void fwd_sd_listen_pid(void) { const char *env; /* * fork & systemd socket activation: * fetch listen pid and update to ours, * when it is set to pid of our parent. */ if ((env = getenv("LISTEN_PID"))) { char *ptr; long l; errno = 0; l = strtol(env, &ptr, 10); if (errno != 0) return; if (ptr == env) return; if (*ptr != '\0') return; if (l < 0) return; if (getppid() == (pid_t)l) { char buf[24]; snprintf(buf, sizeof(buf), "%d", getpid()); setenv("LISTEN_PID", buf, 1); } } } Further, the loop in sd_listen_fds setting FD_CLOEXEC disallows to use the sd_listen_fds use in startproc or in the daemons before fork is done: for (fd = SD_LISTEN_FDS_START; fd < SD_LISTEN_FDS_START + (int) l; fd ++) { int flags; if ((flags = fcntl(fd, F_GETFD)) < 0) { r = -errno; goto finish; } if (flags & FD_CLOEXEC) continue; if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) < 0) { r = -errno; goto finish; } } [or you have to manually revert this...] Could you also try to add either a parameter to sd_listen_fds to skip setting of the FD_CLOEXEC flag or a variant of the function not doing this? And please again - try to provide alls this as library ... Thanks in advance! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c10 --- Comment #10 from Marius Tomaschewski 2011-02-10 16:21:00 UTC --- BTW: The patch is just written down without any test. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c12 --- Comment #12 from Dr. Werner Fink 2011-02-11 09:23:36 UTC --- (In reply to comment #11) Why do you think that third party boot scripts written accordingly to the LSB specs should be rewritten into native service files ;? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c14 --- Comment #14 from Kay Sievers 2011-02-11 09:51:34 UTC --- One of the main goals of systemd is to get rind of the piles of crap accumulated in sysv scripts and /etc/sysconfig/. The SUSE syslog script is a fine example of what we really don't want to see anymore. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c16 --- Comment #16 from Dr. Werner Fink 2011-02-11 13:10:23 UTC --- .. and this is the reason why /etc/rc.d/init.d/functions on a feadora host includes systemd support? AFAIK if the `functions' file is sourced the sourcing script is redirected through systemctl if [ $PPID -ne 1 -a -z "$SYSTEMCTL_SKIP_REDIRECT" ] && \ ( /bin/mountpoint -q /cgroup/systemd || /bin/mountpoint -q /sys/fs/cgroup/systemd ) ; then case "$0" in /etc/init.d/*|/etc/rc.d/init.d/*) _use_systemctl=1 ;; esac fi [...] systemctl_redirect () { local s local prog=${1##*/} local command=$2 case "$command" in start) s=$"Starting $prog (via systemctl): " ;; stop) s=$"Stopping $prog (via systemctl): " ;; reload|try-reload) s=$"Reloading $prog configuration (via systemctl): " ;; restart|try-restart|condrestart) s=$"Restarting $prog (via systemctl): " ;; esac action "$s" /bin/systemctl $command "$prog.service" } [...] if [ "$_use_systemctl" = "1" ]; then if [ "x$1" = xstart -o \ "x$1" = xstop -o \ "x$1" = xrestart -o \ "x$1" = xreload -o \ "x$1" = xtry-restart -o \ "x$1" = xforce-reload -o \ "x$1" = xcondrestart ] ; then systemctl_redirect $0 $1 exit $? fi fi -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c18 --- Comment #18 from Kay Sievers 2011-02-11 18:26:23 UTC --- (In reply to comment #17)

...

Third-party scripts run in compat mode and can not make use of socket-activation.

They can, they do already, and it works well.

That's really not the point. The goal is to clean up the mess here, not to add more hacks.

(In reply to comment #14)

...

One of the main goals of systemd is to get rind of the piles of crap accumulated in sysv scripts and /etc/sysconfig/. The SUSE syslog script is a fine example of what we really don't want to see anymore.

But you'll see it on 11.4 :-)

Sure, no problem. We don't have to touch it, it should work. rsyslog has all merged upstream, can disable the sysv script, and is expected to work properly with the provided native systemd service files. The other syslogs probably work fine in compat mode. We might just don't get early boot messages and have no race-free syslog restart.

We may either write a /sbin/syslog-daemon wrapper in C allowing to switch between the daemons or adopt all syslog daemon packages to conflict with each other so every one can install a syslog.service file.

We really don't want legacy scripts wrapping services along with socket-activation. It's a complete backwards idea.

These 2 functions are *required* to implement this functionality in Type=forking service.

Systemd-patched/aware services should never fork. That's only there to support legacy services, which don't use socket-activation.

When you don't like it, we can also revert all the changes in all the syslog-daemons and wait until there is a lib providing this functionality.

See also comment 7.

There is no lib so far. We might get there, but not now. Most stuff is already merged upstream. When the time comes we can update the stuff, for now there is no library, and SUSE will not create one on their own.

...

Please use the old sysv scripts and leave the limited functionality as it is,

There is _no_ limited functionality. The socket activation works out-of-the box with the init script -- you'd see it, when you'd read the lsof output in bug 656104 comment 21 I mentioned above.

Sure, but it's not the way we like it to have. We really don't run sysv scripts combined with socket activation.

...

or use native service files if systemd features are wanted.

Definitively not for 11.4, see above.

Sure, no problem.

All this systemd stuff were requested far too late to make such intrusive changes.

Maybe. I didn't "request" anything. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c20 --- Comment #20 from Kay Sievers 2011-02-13 21:55:26 UTC --- (In reply to comment #16)

... and this is the reason why /etc/rc.d/init.d/functions on a feadora host includes systemd support? AFAIK if the `functions' file is sourced the sourcing script is redirected through systemctl

Here is the current Fedora guideline: "Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy, but Fedora still contains init mechanisms such as upstart which do not support the systemd unit file format. If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins." https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c22 --- Comment #22 from Marius Tomaschewski 2011-02-14 10:18:47 UTC --- (In reply to comment #19)

(In reply to comment #16)

...

... and this is the reason why /etc/rc.d/init.d/functions on a fedora host includes systemd support?

Sure they support legacy and third-party services. They are in the transition phase currently. sysv will go away for them, and all new stuff is expected to put sysv init scripts in sub rpms, that don't get installed by default, if really needed.

(In reply to comment #20)

(In reply to comment #16)

...

... and this is the reason why /etc/rc.d/init.d/functions on a feadora host includes systemd support? AFAIK if the `functions' file is sourced the sourcing script is redirected through systemctl

Here is the current Fedora guideline:

"Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy, but Fedora still contains init mechanisms such as upstart which do not support the systemd unit file format. If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins."

https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft

Well, I don't really have any problem to make it same way -- but for 12.0 and not for 11.4, where we've released RC1 already and where it was not really possible to test on system running with systemd [I wrote a systemd dummy to make the initial syslog tests] for a too long time and there is not even a stable API/ABI for the daemons. Note: I know, it was not alone systemd fault, but there were problems with the kernel. So as far as I see, this bug tends to become a blocker for 12.0... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=656259 https://bugzilla.novell.com/show_bug.cgi?id=656259#c24 Kay Sievers changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |WONTFIX --- Comment #24 from Kay Sievers 2011-03-14 15:50:33 UTC --- Providing a library is an upstream decision, and it's currently not done for several mentioned reasons. If upstream provides a proper library, SUSE will ship one, if it doesn't, we will not. The stuff is just not ready to be done that way today. This should all be discussed upstream and not tracked in the Novell bugzilla. Closing it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.