Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Tue, Mar 8, 2011 at 1:49 AM, Lennart Poettering wrote: > Heya, > > in the past weeks a couple of folks have been asking about the rsyslog > and systemd glue in systemd, and I never responded since this was still > work in progress. Things should be all resolved now, so here's a > heads-up in how things should work now: > > I have just sent a patch to rsyslog upstream: > > http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch > > This has the effect of making rsyslog and systemd-kmsg-syslogd listen on > the exact same socket, so that we can start the latter during early boot > and then replace it with the former during late boot, thus providing > continuous logging from the point in time we systemd gets invoked up all > the way to the end. And since systemd-kmsg-syslogd writes all /dev/log > messages to kmsg and rsyslog flushes kmsg to disk as first thing we end > up with a full set of messages on disk. > > For this to work properly you need to run current git (I'll probably > release systemd 20 very soon though). > Testing v20 + rsyslog 5.6.2 + above patch I lose at least startup message from rsyslog itself. Do I need newer version of rsyslog? I must admit that I applied this patch on top of another one which added systemd support, but it contained just systemd unit and suild-sys stuff. Is any magic in rsyslogd itself required? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Tue, 08.03.11 23:08, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > On Tue, Mar 8, 2011 at 1:49 AM, Lennart Poettering > wrote: > > Heya, > > > > in the past weeks a couple of folks have been asking about the rsyslog > > and systemd glue in systemd, and I never responded since this was still > > work in progress. Things should be all resolved now, so here's a > > heads-up in how things should work now: > > > > I have just sent a patch to rsyslog upstream: > > > > http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch > > > > This has the effect of making rsyslog and systemd-kmsg-syslogd listen on > > the exact same socket, so that we can start the latter during early boot > > and then replace it with the former during late boot, thus providing > > continuous logging from the point in time we systemd gets invoked up all > > the way to the end. And since systemd-kmsg-syslogd writes all /dev/log > > messages to kmsg and rsyslog flushes kmsg to disk as first thing we end > > up with a full set of messages on disk. > > > > For this to work properly you need to run current git (I'll probably > > release systemd 20 very soon though). > > > > Testing v20 + rsyslog 5.6.2 + above patch I lose at least startup > message from rsyslog itself. Do I need newer version of rsyslog? I > must admit that I applied this patch on top of another one which added > systemd support, but it contained just systemd unit and suild-sys > stuff. Is any magic in rsyslogd itself required? Oh. Uh. I doubt that the startup message from rsyslog itself ever passes through anything socket-like at all, or anything systemd could interfere with. I'd assume this is is done in rsyslog internally. I based my work on the current version 5.7.7. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Mon, 7 Mar 2011 23:49:45 +0100 Lennart Poettering wrote: > Heya, > > in the past weeks a couple of folks have been asking about the rsyslog > and systemd glue in systemd, and I never responded since this was still > work in progress. Things should be all resolved now, so here's a > heads-up in how things should work now: > > I have just sent a patch to rsyslog upstream: > > http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch Is there any reason why it resorts to "ExecStartPre=/bin/systemctl stop ..." instead of just using "Conflicts=systemd-kmsg-syslogd.service"? Both seem to equally work for me, but I wonder if there's some subtle pitfall in Conflicts= for this case, so you avoid to use it. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Fri, Mar 11, 2011 at 7:15 AM, Mike Kazantsev wrote: > On Mon, 7 Mar 2011 23:49:45 +0100 > Lennart Poettering wrote: > >> Heya, >> >> in the past weeks a couple of folks have been asking about the rsyslog >> and systemd glue in systemd, and I never responded since this was still >> work in progress. Things should be all resolved now, so here's a >> heads-up in how things should work now: >> >> I have just sent a patch to rsyslog upstream: >> >> http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch > > Is there any reason why it resorts to "ExecStartPre=/bin/systemctl > stop ..." instead of just using "Conflicts=systemd-kmsg-syslogd.service"? > It prevents systemd-kmsg-syslog bridge to be started at all on entering multi-user. Only one of conflicting units can be started during transaction. systemd[1]: Trying to enqueue job multi-user.target/start/replace systemd[1]: Looking at job systemd-kmsg-syslogd.service/stop conflicted_by=yes systemd[1]: Looking at job systemd-kmsg-syslogd.service/start conflicted_by=no systemd[1]: Fixing conflicting jobs by deleting job systemd-kmsg-syslogd.service/start > Both seem to equally work for me, Well ... without systemd-kmsg-syslogd, you rely on kernel to buffer all data until rsyslogd is started;all datagrams beyond backlog size (default 128) are lost. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Fri, 11.03.11 09:15, Mike Kazantsev (mk.frag...@gmail.com) wrote: > On Mon, 7 Mar 2011 23:49:45 +0100 > Lennart Poettering wrote: > > > Heya, > > > > in the past weeks a couple of folks have been asking about the rsyslog > > and systemd glue in systemd, and I never responded since this was still > > work in progress. Things should be all resolved now, so here's a > > heads-up in how things should work now: > > > > I have just sent a patch to rsyslog upstream: > > > > http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch > > Is there any reason why it resorts to "ExecStartPre=/bin/systemctl > stop ..." instead of just using "Conflicts=systemd-kmsg-syslogd.service"? > > Both seem to equally work for me, but I wonder if there's some subtle > pitfall in Conflicts= for this case, so you avoid to use it. They do different things. The bootup transaction covers the entire boot. If you use Conflicts= then only one of the to syslog implementations can be part of it, and the other is removed. However we want both syslogs to be part of the transaction, and both started, one during early boot and one during late boot. Hence we allow both in the transaction, but modify the transaction later on when rsyslog is ready to start. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Fri, 11.03.11 09:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > Both seem to equally work for me, > > Well ... without systemd-kmsg-syslogd, you rely on kernel to buffer > all data until rsyslogd is started;all datagrams beyond backlog size > (default 128) are lost. backlog is not the right term, as that is appropriate for SOCK_STREAM sockets only where you call listen(). The /dev/log socket we use is SOCK_DGRAM however. How much data we can queue in that is controlled via SO_RCVBUF and is quite large by default, but can easily be exhausted if you get a lot of selinux AVCs for example... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Fri, 11 Mar 2011 16:55:28 +0100 Lennart Poettering wrote: > On Fri, 11.03.11 09:15, Mike Kazantsev (mk.frag...@gmail.com) wrote: > > > On Mon, 7 Mar 2011 23:49:45 +0100 > > Lennart Poettering wrote: > > > > > Heya, > > > > > > in the past weeks a couple of folks have been asking about the rsyslog > > > and systemd glue in systemd, and I never responded since this was still > > > work in progress. Things should be all resolved now, so here's a > > > heads-up in how things should work now: > > > > > > I have just sent a patch to rsyslog upstream: > > > > > > http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch > > > > Is there any reason why it resorts to "ExecStartPre=/bin/systemctl > > stop ..." instead of just using "Conflicts=systemd-kmsg-syslogd.service"? > > > > Both seem to equally work for me, but I wonder if there's some subtle > > pitfall in Conflicts= for this case, so you avoid to use it. > > They do different things. > > The bootup transaction covers the entire boot. If you use Conflicts= > then only one of the to syslog implementations can be part of it, and > the other is removed. However we want both syslogs to be part of the > transaction, and both started, one during early boot and one during late > boot. Hence we allow both in the transaction, but modify the transaction > later on when rsyslog is ready to start. Understood. Still, syslog.socket is the thing that gets into a bootup transaction, not the systemd-kmsg-syslogd.service, right? Guess the latter just won't be started as long as rsyslog.service hangs in the jobs queue, produced by that transaction. Btw, rsyslog.service seem to be installed into multi-user.target.wants, why not syslog.target, which seem to indicate the point where proper syslog daemon is running (according to systemd.special(7))? > > Lennart > -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev wrote: > On Fri, 11 Mar 2011 16:55:28 +0100 > Lennart Poettering wrote: > >> On Fri, 11.03.11 09:15, Mike Kazantsev (mk.frag...@gmail.com) wrote: >> >> > On Mon, 7 Mar 2011 23:49:45 +0100 >> > Lennart Poettering wrote: >> > >> > > Heya, >> > > >> > > in the past weeks a couple of folks have been asking about the rsyslog >> > > and systemd glue in systemd, and I never responded since this was still >> > > work in progress. Things should be all resolved now, so here's a >> > > heads-up in how things should work now: >> > > >> > > I have just sent a patch to rsyslog upstream: >> > > >> > > http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch >> > >> > Is there any reason why it resorts to "ExecStartPre=/bin/systemctl >> > stop ..." instead of just using "Conflicts=systemd-kmsg-syslogd.service"? >> > >> > Both seem to equally work for me, but I wonder if there's some subtle >> > pitfall in Conflicts= for this case, so you avoid to use it. >> >> They do different things. >> >> The bootup transaction covers the entire boot. If you use Conflicts= >> then only one of the to syslog implementations can be part of it, and >> the other is removed. However we want both syslogs to be part of the >> transaction, and both started, one during early boot and one during late >> boot. Hence we allow both in the transaction, but modify the transaction >> later on when rsyslog is ready to start. > > Understood. > > Still, syslog.socket is the thing that gets into a bootup transaction, > not the systemd-kmsg-syslogd.service, right? > Guess the latter just won't be started as long as rsyslog.service > hangs in the jobs queue, produced by that transaction. > But then it won't be stopped either as Conflicts covers only initial transaction creation. It does not mean "stop other service when this one is started". Unfortunately :) > Btw, rsyslog.service seem to be installed into multi-user.target.wants, > why not syslog.target, which seem to indicate the point where proper > syslog daemon is running (according to systemd.special(7))? > Actually good question (same as for portmap) - who should pull in syslog.target then? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
2011/3/11 Andrey Borzenkov : > On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev wrote: > >> Btw, rsyslog.service seem to be installed into multi-user.target.wants, >> why not syslog.target, which seem to indicate the point where proper >> syslog daemon is running (according to systemd.special(7))? >> > > Actually good question (same as for portmap) - who should pull in > syslog.target then? Yeah, I noticed this myself already. Quite a bit of syslog output ended up in /proc/kmsg during boot because rsyslog was started rather late (via multi-user.target). Afaics, there is not explicit symlink pulling in syslog.target, so I assume it is handled internally by systemd. Lennart? That said, I agree that rsyslog.service should be pulled in via syslog.target.wants and not multi-user.target.wants. Cheers, Michae -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
2011/3/12 Michael Biebl : > 2011/3/11 Andrey Borzenkov : >> On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev wrote: > >> >>> Btw, rsyslog.service seem to be installed into multi-user.target.wants, >>> why not syslog.target, which seem to indicate the point where proper >>> syslog daemon is running (according to systemd.special(7))? >>> >> >> Actually good question (same as for portmap) - who should pull in >> syslog.target then? > > Yeah, I noticed this myself already. Quite a bit of syslog output > ended up in /proc/kmsg during boot because rsyslog was started rather > late (via multi-user.target). > Afaics, there is not explicit symlink pulling in syslog.target, so I > assume it is handled internally by systemd. Lennart? Turns out, that indeed syslog.target is not automatically started. I symlinked syslog.target into multi-user.target.wants and rsyslog.service into syslog.target.wants. Now all services with After=syslog.target are correctly started after rsyslog.service. Lennart, I think we should add those changes to systemd and rsyslog.service. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Fri, 11.03.11 23:10, Mike Kazantsev (mk.frag...@gmail.com) wrote: > On Fri, 11 Mar 2011 16:55:28 +0100 > Lennart Poettering wrote: > > > On Fri, 11.03.11 09:15, Mike Kazantsev (mk.frag...@gmail.com) wrote: > > > > > On Mon, 7 Mar 2011 23:49:45 +0100 > > > Lennart Poettering wrote: > > > > > > > Heya, > > > > > > > > in the past weeks a couple of folks have been asking about the rsyslog > > > > and systemd glue in systemd, and I never responded since this was still > > > > work in progress. Things should be all resolved now, so here's a > > > > heads-up in how things should work now: > > > > > > > > I have just sent a patch to rsyslog upstream: > > > > > > > > http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch > > > > > > Is there any reason why it resorts to "ExecStartPre=/bin/systemctl > > > stop ..." instead of just using "Conflicts=systemd-kmsg-syslogd.service"? > > > > > > Both seem to equally work for me, but I wonder if there's some subtle > > > pitfall in Conflicts= for this case, so you avoid to use it. > > > > They do different things. > > > > The bootup transaction covers the entire boot. If you use Conflicts= > > then only one of the to syslog implementations can be part of it, and > > the other is removed. However we want both syslogs to be part of the > > transaction, and both started, one during early boot and one during late > > boot. Hence we allow both in the transaction, but modify the transaction > > later on when rsyslog is ready to start. > > Understood. > > Still, syslog.socket is the thing that gets into a bootup transaction, > not the systemd-kmsg-syslogd.service, right? It gets pulled in via: /lib/systemd/system/sysinit.target.wants/systemd-kmsg-syslogd.service > Btw, rsyslog.service seem to be installed into multi-user.target.wants, > why not syslog.target, which seem to indicate the point where proper > syslog daemon is running (according to systemd.special(7))? Hmm, good question. Currently only syslog.socket is pulled in by syslog.target. This should normally be enough I guess and we should keep those meta-targets as small as possible I guess, to make bootup fast. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Sat, 12.03.11 00:15, Michael Biebl (mbi...@gmail.com) wrote: > > 2011/3/11 Andrey Borzenkov : > > On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev > > wrote: > > > > >> Btw, rsyslog.service seem to be installed into multi-user.target.wants, > >> why not syslog.target, which seem to indicate the point where proper > >> syslog daemon is running (according to systemd.special(7))? > >> > > > > Actually good question (same as for portmap) - who should pull in > > syslog.target then? > > Yeah, I noticed this myself already. Quite a bit of syslog output > ended up in /proc/kmsg during boot because rsyslog was started rather > late (via multi-user.target). > Afaics, there is not explicit symlink pulling in syslog.target, so I > assume it is handled internally by systemd. Lennart? Nope. There's nothing magic that pulls syslog.target in. > That said, I agree that rsyslog.service should be pulled in via > syslog.target.wants and not multi-user.target.wants. Hmm, as mentioned the current thinking there is to hook as little into the targets as necessary to fulfill what they are needed for. And that is for syslog.target just syslog.socket, not the full rsyslog.service which can start much later. But I am a bit torn about this. It might be worth changing this. Dunno. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Sat, 12.03.11 01:14, Michael Biebl (mbi...@gmail.com) wrote: > > 2011/3/12 Michael Biebl : > > 2011/3/11 Andrey Borzenkov : > >> On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev > >> wrote: > > > >> > >>> Btw, rsyslog.service seem to be installed into multi-user.target.wants, > >>> why not syslog.target, which seem to indicate the point where proper > >>> syslog daemon is running (according to systemd.special(7))? > >>> > >> > >> Actually good question (same as for portmap) - who should pull in > >> syslog.target then? > > > > Yeah, I noticed this myself already. Quite a bit of syslog output > > ended up in /proc/kmsg during boot because rsyslog was started rather > > late (via multi-user.target). > > Afaics, there is not explicit symlink pulling in syslog.target, so I > > assume it is handled internally by systemd. Lennart? > > Turns out, that indeed syslog.target is not automatically started. > I symlinked syslog.target into multi-user.target.wants and > rsyslog.service into syslog.target.wants. > > Now all services with After=syslog.target are correctly started after > rsyslog.service. > > Lennart, I think we should add those changes to systemd and rsyslog.service. I think we should pull in rsyslog.target by default, but I am not convinced that rsyslog.service should hook itself into syslog.target. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
2011/3/16 Lennart Poettering : > On Sat, 12.03.11 01:14, Michael Biebl (mbi...@gmail.com) wrote: > >> >> 2011/3/12 Michael Biebl : >> > 2011/3/11 Andrey Borzenkov : >> >> On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev >> >> wrote: >> > >> >> >> >>> Btw, rsyslog.service seem to be installed into multi-user.target.wants, >> >>> why not syslog.target, which seem to indicate the point where proper >> >>> syslog daemon is running (according to systemd.special(7))? >> >>> >> >> >> >> Actually good question (same as for portmap) - who should pull in >> >> syslog.target then? >> > >> > Yeah, I noticed this myself already. Quite a bit of syslog output >> > ended up in /proc/kmsg during boot because rsyslog was started rather >> > late (via multi-user.target). >> > Afaics, there is not explicit symlink pulling in syslog.target, so I >> > assume it is handled internally by systemd. Lennart? >> >> Turns out, that indeed syslog.target is not automatically started. >> I symlinked syslog.target into multi-user.target.wants and >> rsyslog.service into syslog.target.wants. >> >> Now all services with After=syslog.target are correctly started after >> rsyslog.service. >> >> Lennart, I think we should add those changes to systemd and rsyslog.service. > > I think we should pull in rsyslog.target by default, but I am not Will that ensure that rsyslog is started before services using After=syslog.target? > convinced that rsyslog.service should hook itself into syslog.target. > What is syslog.target then good for? Reading trough the systemd.special man page it says that syslog.target is the place where the real syslogd should be symlinks into. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Wed, Mar 16, 2011 at 9:17 AM, Michael Biebl wrote: > 2011/3/16 Lennart Poettering : >> On Sat, 12.03.11 01:14, Michael Biebl (mbi...@gmail.com) wrote: >> >>> >>> 2011/3/12 Michael Biebl : >>> > 2011/3/11 Andrey Borzenkov : >>> >> On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev >>> >> wrote: >>> > >>> >> >>> >>> Btw, rsyslog.service seem to be installed into multi-user.target.wants, >>> >>> why not syslog.target, which seem to indicate the point where proper >>> >>> syslog daemon is running (according to systemd.special(7))? >>> >>> >>> >> >>> >> Actually good question (same as for portmap) - who should pull in >>> >> syslog.target then? >>> > >>> > Yeah, I noticed this myself already. Quite a bit of syslog output >>> > ended up in /proc/kmsg during boot because rsyslog was started rather >>> > late (via multi-user.target). >>> > Afaics, there is not explicit symlink pulling in syslog.target, so I >>> > assume it is handled internally by systemd. Lennart? >>> >>> Turns out, that indeed syslog.target is not automatically started. >>> I symlinked syslog.target into multi-user.target.wants and >>> rsyslog.service into syslog.target.wants. >>> >>> Now all services with After=syslog.target are correctly started after >>> rsyslog.service. >>> >>> Lennart, I think we should add those changes to systemd and rsyslog.service. >> >> I think we should pull in rsyslog.target by default, but I am not > > Will that ensure that rsyslog is started before services using > After=syslog.target? > See my suggestion in http://lists.freedesktop.org/archives/systemd-devel/2011-March/001600.html IMHO it is saner approach than just throwing in all virtual targets by default. >> convinced that rsyslog.service should hook itself into syslog.target. >> > > What is syslog.target then good for? I consider it to be more of a virtual provide for specific syslog implementation. > Reading trough the systemd.special man page it says that syslog.target > is the place where the real syslogd should be symlinks into. > | man can be fixed if needed :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Wed, 16.03.11 07:17, Michael Biebl (mbi...@gmail.com) wrote: > >> > Yeah, I noticed this myself already. Quite a bit of syslog output > >> > ended up in /proc/kmsg during boot because rsyslog was started rather > >> > late (via multi-user.target). > >> > Afaics, there is not explicit symlink pulling in syslog.target, so I > >> > assume it is handled internally by systemd. Lennart? > >> > >> Turns out, that indeed syslog.target is not automatically started. > >> I symlinked syslog.target into multi-user.target.wants and > >> rsyslog.service into syslog.target.wants. > >> > >> Now all services with After=syslog.target are correctly started after > >> rsyslog.service. > >> > >> Lennart, I think we should add those changes to systemd and > >> rsyslog.service. > > > > I think we should pull in rsyslog.target by default, but I am not > > Will that ensure that rsyslog is started before services using > After=syslog.target? No. Unless we do the second change. > > > convinced that rsyslog.service should hook itself into syslog.target. > > > > What is syslog.target then good for? if you pull that in you know that /dev/log can be written to. In case of a socket activated syslog this means that if you pull that in you can rely that the socket is established, but there's no guarantee that the daemon is actually up. In case of a classic non-socket-activated syslog this is more traditional however, and if syslog.target is reached then syslog is completely running. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PACKAGERS] rsyslog and systemd
On Wed, 16.03.11 10:58, Andrey Borzenkov (arvidj...@mail.ru) wrote: > >> convinced that rsyslog.service should hook itself into syslog.target. > >> > > > > What is syslog.target then good for? > > I consider it to be more of a virtual provide for specific syslog > implementation. My look on the whole situation is actually that these targets are stopgaps in a world where not all daemons are socket activatable and where some daemons are written in a way that they assume that the network is always up and does not change dynamically. In a world where where all services are socket activatable and all daemons subscribe properly to netlink we don't need neither syslog.target nor network.target, because the syslog daemon is always accessible and it doesn't matter anymore when the network is configured and when not. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
