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?

As of now, it's an upstream decision not to provide such library.

As long as that doesn't change, SUSE will also not have one.

(Lennart is 3 weeks on the road, and might not be available to make any such decisions)

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.

Created attachment 402465 [details]
Patch for Makefile.am in git master to enable the library

I didn't tested it yet, because of some build system trouble.

(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.

It would be easy to do it, sure, but for now it was decided not to do it. SUSE will just follow upstream here.

There would be circular (build) dependencies with projects systemd links against like udev and dbus.

The simple way it's done, and the names of the environment vars are intentionally not systemd specific, and projects can implement the simple logic in whatever way they like. The original idea was to convince the upstart maintainer to do the same thing for socket activation.

There is no real stable API/ABI at the moment, hence there should be no C library for others to link against.

We will get to all that eventually, especially when there will be more complicated things to do than wrap getenv() -- but all this is unlikely to happen in the next couple of weeks.

Not having a stable API sounds like a good reason not to adapt our daemons ;(

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!

Created attachment 413346 [details]
Example git patch adding the functions

BTW: The patch is just written down without any test.

Oh my god. :)

Please use native service files and not startproc and the old init scripts.

(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 ;?

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

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.

Fedora even disallows packaging sysv scripts in RPMs now. So we can not expect any upstream support for hacks like faking the systemd provided socket passing properties across forking processes. That's really not how things are meant to be done in systemd land.

Please use the old sysv scripts and leave the limited functionality as it is, or use native service files if systemd features are wanted.

... 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

(In reply to comment #13)
> Third-party scripts run in compat mode and can not make use of
> socket-activation.

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

(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 :-)

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.

But all this will definitively not happen for 11.4.
Except you do it yourself, became bugowner of all syslog daemons and it
will be accepted for 11.4...


(In reply to comment #15)
> Fedora even disallows packaging sysv scripts in RPMs now. So we can not expect
> any upstream support for hacks like faking the systemd provided socket passing
> properties across forking processes. That's really not how things are meant to
> be done in systemd land.

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

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.

> 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.

> or use native service files if systemd features are wanted.

Definitively not for 11.4, see above.

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

(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.

(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 #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

(In reply to comment #18)
> (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.

No, the point is that you don't read what people are writting to you.

As I wrote, we'll not change the the syslog-daemon switch for 11.4.

It was simply far too late to make all these update-intrusive changes
as required, because systemd didn't worked reliably until end of 2010.

And also, because you still didn't fixed this bug (even the library
exists, but is simply not installed).

> > (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.

Nonsense.

You still didn't read the comments in the bug reports, but just blame
all people they're doing "crap" and "mess".

So read this here please:

  All 3 syslog daemons (syslogd,syslog-ng and rsyslog) natively support
  systemd socket activation:
   - in "Type=simple" as well as in "Type=forking" systemd.service(5)
     mode and
   - for all unix dgram sockets systemd provides to them (that is also
     for the $chroot/dev/log sockets).

  We've added the required functionality to all of them upstream.

  The code required to implement the "Type=forking" is attached in
  comment #9.

  _Please_ forward it upstream and ship install the lib providing it.

All patches are upstream - usually in git master, but our packages
include these patches.

> > 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.

And I'll really not change the syslog-daemon switch for 11.4, because
it is too late due to systemd problems until end of 2010 and the change
of the syslog daemon switch is very intrusive.

Perhaps you didn't noticed, but we've released RC1 already.

For 12.0 (or whatever follows the 11.4), we can change the daemon switch.

> > 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.

systemd supports also socket activation in Type=forking services mode.

> > 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.

And until there is a stable systemd lib, we'll not change the syslog
daemon switch.

> > All this systemd stuff were requested far too late to make such
> > intrusive changes.
> 
> Maybe. I didn't "request" anything.

There are (multiple AFAIS) feature requests to integrate systemd and
you are assigned as developer for them. further, *you* asked to adopt
the syslog daemons.

(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...

(In reply to comment #21)
> > 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.

And... it works as implemented now (RC1 + last syslog-ng config typo
fix + sysvinit-tools). They syslog daemons _use_ the socket activation
and race-free syslog restart works - you can switch between the syslog
daemons, see https://bugzilla.novell.com/show_bug.cgi?id=656104#c21 .

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.