Bug 656104

(In reply to comment #0)
> #310327: use systemd session manager instead of SysVinit/upstart

Url is:
https://features.opensuse.org/310327

Sounds nice. Thanks for taking care. Would be great if the patches can be send upstream too, when the services work as expected.

The current sd-daemon.[hc] files to add are here:
  http://cgit.freedesktop.org/systemd/tree/src/sd-daemon.h

Or installed by systemd.rpm in /usr/share/doc/packages/systemd/.

Thanks again!

(In reply to comment #2)

I'm missing /usr/include/sd-daemon.h and also /lib/libsd-daemon.so.0.13
toghether with /usr/lib{64}/libsd-daemon.so ... otherwise the stuff will
not build nor link:

 syslogd/sysklogd-1.4.1> wdiff syslogd.c | grep sd_
 +               r = sd_listen_fds(0);
 +                       r = sd_is_socket_unix(fd, SOCK_DGRAM, -1, _PATH_LOG, 0);

... please provide an appropiate systemd-devel as well as a
libsd-daemon0.rpm ;)

Na, there is no lib, and none planned to have so far. That's why it's not installed. It's just 2 files to copy into the project. They contain very basic logic. The logic can be open-coded too, if necessary.

We will get into dependency problems if we make all services link directly against systemd at that point.

That can be reconsidered later, when there might be more interesting things than gentenv() and stat() to do. :)

IMHO this is will cause trouble ... beside policy and license ... the
interface may change.  And it makes no sence to include the same stuff
several times into the source tree.  Only one error and you have to
change any occurrence of sd-daemon.c.  This is the job for a shared
library and nothing else.

It's included in a ton of projects already, also in rsyslog. And it's BSD licensed.

Anyway not my call, I can just provide what I have, and I don't have a shared lib, and upstream did not want one as of now. That might all be reconsidered later.

... it should be reconsidered ... beside this I'd like also to have the
manual page around as mentioned in sd-daemon.h:

/*
  Returns how many file descriptors have been passed, or a negative
  errno code on failure. Optionally, removes the $LISTEN_FDS and
  $LISTEN_PID file descriptors from the environment (recommended, but
  problematic in threaded environments). If r is the return value of
  this function you'll find the file descriptors passed as fds
  SD_LISTEN_FDS_START to SD_LISTEN_FDS_START+r-1. Returns a negative
  errno style error code on failure. This function call ensures that
  the FD_CLOEXEC flag is set for the passed file descriptors, to make
  sure they are not passed on to child processes. If FD_CLOEXEC shall
  not be set, the caller needs to unset it after this call for all file
  descriptors that are used.

  See sd_listen_fds(3) for more information.
*/
int sd_listen_fds(int unset_environment) _sd_hidden_;

Created attachment 402328 [details]
sysklogd-1.4.1-systemd.dif

Hopefully this patch is correct for the old syslogd

(In reply to comment #7)
> ... it should be reconsidered ... beside this I'd like also to have the
> manual page around as mentioned in sd-daemon.h:

$ rpm -ql systemd | grep fds
/usr/share/man/man3/sd_listen_fds.3.gz

:)

A first, not yet tested rsyslog with systemd support is in Base:System.

Werner,

there are the socket and service files that we've to provide -- here the
rsyslog specific variant:

   $systemdsystemunitdir/rsyslog.service
   [Unit]
   Description=System Logging Service

   [Service]
   ExecStart=/sbin/rsyslogd -n -c 5

   [Install]
   WantedBy=multi-user.target

   $systemdsystemunitdir/rsyslog.socket
   [Unit]
   Description=Syslog Socket

   [Socket]
   ListenDatagram=/dev/log

   [Install]
   WantedBy=sockets.target

They've to go to the common (currently klogd) package. Both, rsyslogd
and syslog-ng do not need klogd, so perhaps it is a good occasion to
move the common things from klogd into a common "syslog" package?

Further, there is also the issue with additional chroot log sockets
(e.g. from dhcp-server). I've not reviewed systemd yet, so at the
moment I've no idea what is required here and what not.

Depends on: bug 656259 comment 5.

Created attachment 404503 [details]
syslog-ng-3.2.1-systemd-integration.bnc656104.diff

I've implemented a first version of systemd socket activation
for unix-dgram sockets (not only /dev/log), because we need
this for the chroot sockets too I think.

Created attachment 404504 [details]
rsyslog-5.6.2-systemd-integration.bnc656104.diff

The current rsyslog patch. Currently the upstream (git master) version
limited to /dev/log.

I gave systemd a try today. My vmware machine froze many times, but it's most likely something kernel related, at least did not depend if I use rsyslog or syslog-ng.

There was notable difference between rsyslog and syslog-ng: dmesg. It's OK with rsyslog, but with syslog-ng dmesg only shows garbage, just the date and the '[' sign many times. Right now I'm unable to boot, so can't quote the exact message...

Please give also the old syslogd a try to see if this works
flawless together with systemd, thanks.

Created attachment 413031 [details]
startproc: socket activation forwarding

Werner,

please review the following request and forward to openSUSE:Factory:

 60429  State:new     By:mtomaschewski When:2011-02-09T15:35:09
        submit:       home:mtomaschewski:branches:Base:System/sysvinit  ->  Base:System            
        Descr: socket activation forwarding (bnc#656104)

It is the last puzzle piece and we can close the bug then -- all syslog
daemons already support socket activated unix sockets.

Yes, thanks a lot.  As I'm currently working on start/killproc
I'll add this one as well.

Btw: How about a small library with an actual systemd
socket activation code instead of including the code
several times?

Maybe also having cgroup support for start/killproc would also
an option. What do you think?

Created attachment 413292 [details]
startproc: socket activation forwarding

this one works even if -e is choosen on the startproc commandline
Marius ... does this work for you?

Thanks! Looks good, going to retest it.

Yes,
works perfectly: same socket node [2666 here] used by systemd and syslog
daemon process - also after a switch to another syslog daemon:

abraxas7:~ # lsof | grep "/dev/log"
systemd      1           root   25u     unix 0xffff88001cb86700      0t0       2666 /dev/log
systemd-k  290           root    3w     unix 0xffff88001cb86700      0t0       2666 /dev/log
syslog-ng 1938           root    3u     unix 0xffff88001cb86700      0t0       2666 /dev/log
syslog-ng 1939           root    3u     unix 0xffff88001cb86700      0t0       2666 /dev/log
abraxas7:~ # vi /etc/sysconfig/syslog
abraxas7:~ # systemctl restart syslog.service
abraxas7:~ # lsof | grep "/dev/log"
systemd      1           root   25u     unix 0xffff88001cb86700      0t0       2666 /dev/log
systemd-k  290           root    3w     unix 0xffff88001cb86700      0t0       2666 /dev/log
syslogd   2053           root    3u     unix 0xffff88001cb86700      0t0       2666 /dev/log
abraxas7:~ # vi /etc/sysconfig/syslog
abraxas7:~ # systemctl restart syslog.service
abraxas7:~ # lsof | grep "/dev/log"
systemd      1            root   25u     unix 0xffff88001cb86700      0t0       2666 /dev/log
systemd-k  290            root    3w     unix 0xffff88001cb86700      0t0       2666 /dev/log
rsyslogd  2083            root    3u     unix 0xffff88001cb86700      0t0       2666 /dev/log
rs:main   2083 2084       root    3u     unix 0xffff88001cb86700      0t0       2666 /dev/log
rsyslogd  2083 2085       root    3u     unix 0xffff88001cb86700      0t0       2666 /dev/log
rsyslogd  2083 2086       root    3u     unix 0xffff88001cb86700      0t0       2666 /dev/log
rsyslogd  2083 2087       root    3u     unix 0xffff88001cb86700      0t0       2666 /dev/log
abraxas7:~ # systemctl status syslog.service
syslog.service - LSB: Start the system logging daemons
          Loaded: loaded (/etc/init.d/syslog)
          Active: active (running) since Thu, 10 Feb 2011 15:58:37 +0100; 30s ago
         Process: 2063 ExecStop=/etc/init.d/syslog stop (code=exited, status=0/SUCCESS)
         Process: 2073 ExecStart=/etc/init.d/syslog start (code=exited, status=0/SUCCESS)
        Main PID: 2083 (rsyslogd)
          CGroup: name=systemd:/system/syslog.service
                  └ 2083 /sbin/rsyslogd -c 5 -f /etc/rsyslog.conf

[syslog-ng from Base:System, due to a typo in spec file causing incorrect
 modules.conf on RC1 (bnc##664931#c5)].

(In reply to comment #18)
> Btw: How about a small library with an actual systemd socket activation
> code instead of including the code several times?

We have bug 656259 open because of this. I don't think it makes sense to
reimplement it and provide own library... same as I don't think this gets
fixed for 11.4 :-(

What would make sense is to try to add the functionality to forward [inherit]
the sockets to a child into upstream code. Further, also to add an option to
sd_listen_fds to not set FD_CLOEXEC flags (or add a variant of the function
avoiding this), so we can use these functions in startproc and in fork code
of the daemons...

> Maybe also having cgroup support for start/killproc would also
> an option. What do you think?

This sounds like a good idea.

Removed the bnc#656259 dependency to be able to close this bug.

OK, all works fine for me => FIXED.

(In reply to comment #22)
> What would make sense is to try to add the functionality to forward [inherit]
> the sockets to a child into upstream code. Further, also to add an option to
> sd_listen_fds to not set FD_CLOEXEC flags (or add a variant of the function
> avoiding this), so we can use these functions in startproc and in fork code
> of the daemons...

I could try to remove FD_CLOEXEC in closefds() as I use this function to
set this flag for all other file descriptors.

Yes, of course this is possible, but I expect the functionality from a systemd
library instead of the current ignorance. I'll not make anything from now on
until the systemd maintainer starts working himself a bit. It is "his" feature.

(In reply to comment #26)
> I'll not make anything from now on
> until the systemd maintainer starts working himself a bit. It is "his" feature.

What do you mean? "I" don't need any feature from syslog.

Hmmm ... I'm pretty sure that syslog was not meant ;)