> I think it is probably better to fail noisily Precisely - make it so the startup fails, and exits nonzero so RC scripts know it failed.
Still, having the option to go back in the case a failure shouldn't result in a non-start is a good idea. The distros will probably want that option, since it makes sure that the service comes up in the case something else is busted. -Aaron On Mon, Jul 11, 2011 at 5:26 PM, <[email protected]> wrote: > I think it is probably better to fail noisily > > thinking out loud here > > it must at least fail with errors to stderr so that someone starting it > manually can see that it can't read the config file. > > this should be for any config failure (i.e. one line it doesn't understand), > not just complete failure > > if it is able to understand the config file enough to get destinations, it > would probably be a good idea to spit logs to those destinations reporting > the failure. This is more shaky, but I think it's probably a good idea. > > David Lang > > On Mon, 11 Jul 2011, Rainer Gerhards wrote: > >> Date: Mon, 11 Jul 2011 23:03:12 +0200 >> From: Rainer Gerhards <[email protected]> >> Reply-To: rsyslog-users <[email protected]> >> To: [email protected] >> Subject: Re: [rsyslog] RFC: Dropping Emergency Config System >> >> Out of my head. It is sysklogd legacy. Four rules, among them >> >> *.err /dev/console >> Panic.* * >> >> Two more. Originally, it also read the system socket, which was lost some >> way around the road. I think it doesnt work for a couple of years now and >> nobody ever noticed. I just came across it due to new config. . . >> Rainer"[email protected]" <[email protected]> hat geschrieben:other than stderr, >> what does the current system try to do? >> >> David Lang >> >> >> On Mon, 11 Jul 2011, Rainer Gerhards wrote: >> >>> Date: Mon, 11 Jul 2011 22:50:18 +0200 >>> From: Rainer Gerhards <[email protected]> >>> Reply-To: rsyslog-users <[email protected]> >>> To: [email protected] >>> Subject: Re: [rsyslog] RFC: Dropping Emergency Config System >>> >>> The question is if we need more than stderr. It is surprisingly >>> complicated to do this in a clean way, as the necessary plumbing is not >>> present. >>> >>> RainerAaron Wiebe <[email protected]> hat geschrieben:There are also >>> pretty valid reasons for having the ability to turn it >>> off. If it's not a compile-time flag today, it should probably be >>> made one. If there are errors, I'd like it to fail out rather than >>> start up anyway in a lot of cases. >>> >>> On Mon, Jul 11, 2011 at 3:19 PM, <[email protected]> wrote: >>>> >>>> systemd is not a valid reason for removing it (systemd is linux-only and >>>> idn't even on all linux systems) >>>> >>>> that being said, as long as rsyslog can spit messages out to stderr to >>>> let >>>> someone know when there are problems starting up, I would not expect it >>>> to >>>> do anything more, and would probably be surprised (in a nasty way) if >>>> rsyslog processed logs and sent them somewhere I didn't specify. >>>> >>>> David Lang >>>> >>>> On Mon, 11 Jul 2011, Rainer Gerhards wrote: >>>> >>>>> Date: Mon, 11 Jul 2011 17:45:58 +0200 >>>>> From: Rainer Gerhards <[email protected]> >>>>> Reply-To: rsyslog-users <[email protected]> >>>>> To: rsyslog-users <[email protected]> >>>>> Subject: [rsyslog] RFC: Dropping Emergency Config System >>>>> >>>>> Hi all, >>>>> >>>>> since long, rsyslog has a so-called "emergency config system" which >>>>> provides >>>>> a very minimal config in case rsyslog can not load the real config. I >>>>> am >>>>> working on that system, which creates some complexity inside the code. >>>>> Most >>>>> importantly, I noticed that somewhere along development, that system >>>>> notably >>>>> degraded, obviously without anybody noticing. All it currently does is >>>>> spit >>>>> out startup error messages to some well known destinations (like the >>>>> system >>>>> console). It does NOT process the kernel log or the regular log socket. >>>>> >>>>> As nobody reported any problems with the system, I guess nobody really >>>>> used >>>>> it. In order to streamline the code, I am about to drop it from v6 >>>>> (even >>>>> more >>>>> so because systemd handles many of the situations this system >>>>> originally >>>>> was >>>>> thought for [1]). Removing helps getting cleaner, less complex and >>>>> faster >>>>> to >>>>> work on code. >>>>> >>>>> Any objections against dropping the emergency config system? If so, >>>>> please >>>>> let know the exact reason because I need to remodel the system in any >>>>> case >>>>> and this feedback would be very useful (plus prove the point that there >>>>> is >>>>> real need for this system ;)). >>>>> >>>>> Thanks, >>>>> Rainer >>>>> >>>>> [1] >>>>> >>>>> http://lists.freedesktop.org/archives/systemd-devel/2011-July/002862.html >>>>> _______________________________________________ >>>>> rsyslog mailing list >>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>> http://www.rsyslog.com >>>>> >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
