Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Santos <casantos@datacom.com.br>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v3 0/8] init scripts: rewrite S01logging
Date: Fri, 2 Nov 2018 19:13:49 -0200 (BRST)	[thread overview]
Message-ID: <1901226171.9682.1541193229814.JavaMail.zimbra@datacom.com.br> (raw)
In-Reply-To: <20181013145512.6a135309@windsurf>

> From: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> To: "DATACOM" <casantos@datacom.com.br>
> Cc: "buildroot" <buildroot@buildroot.org>, "ratbert90" <aduskett@gmail.com>, "Arnout Vandecappelle" <arnout@mind.be>,
> "Peter Korsgaard" <peter@korsgaard.com>, "Yann Morin" <yann.morin.1998@free.fr>
> Sent: S?bado, 13 de outubro de 2018 9:55:12
> Subject: Re: [Buildroot] [PATCH v3 0/8] init scripts: rewrite S01logging

> Hello,
> 
> On Fri, 12 Oct 2018 08:50:49 -0300 (BRT), Carlos Santos wrote:
> 
>> > (1) Do we really want that Busybox, syslog-ng, rsyslog, sysklogd all
>> >     install a file of the same name, S01logging ? Isn't this
>> >     contradicting our goal of not having one package overwrite files
>> >     installed by another package ?
>> > 
>> >     Wouldn't it make more sense to install S01syslog-ng, S01rsyslog,
>> >     S01sysklogd ? This way, we also have a mapping between the init
>> >     script name and the daemon/package being started ?
>> 
>> I don't know why it was decided to use the same name for all packages.
>> Looks like the original intention was to prevent multiple logging damons
>> from running at the same time.
> 
> Yes, but why? If we go down this route, then all web servers should
> install S50httpd, and not S50lighttpd, S50apache, etc. Dropbear and
> OpenSSH should not install S50dropbear and S50sshd, etc.
> 
>> Perhaps we should add an item to the "System configuration" menu allowing
>> the user to choose a logging provider, just like the "Init system" item,
>> and convert rsyslog/sysklogd/syslog-ng to virtual packages.
> 
> I don't think we want to do that, because then we need to do this for
> "what mail server do you want?", "what http server do you want?", "what
> SSH server do you want?", etc.
> 
> If you enable two SSH servers, the second to start will fail. If you
> enable two HTTP servers, the second to start will fail, etc. Similarly,
> if you enable two logging daemons, it will not work nicely.
> 
> I don't think we should solve that problem, and just leave it up to the
> user to do a configuration that makes sense. If you enable two SSH
> servers or two logging daemons, your configuration doesn't make sense,
> and it should be fixed.

Did I ever suggest adding menus to select HTTP and SSH servers? Let's stick
to what was said, please.

>> > (2) For the Busybox case, do we want to keep a single init script that
>> >     starts both klogd and syslogd ? Or should we have one init script
>> >     per daemon, so that again the init script name matches the daemon
>> >     being started ? So S01klogd, S01syslogd ?
>> 
>> There is also sysklogd, from which Busyox borrowed the code (or at least
>> the idea) a long time ago. I think we should keep klogd and syslogd tied
>> to each other, since klogd does not make much sense without syslogd.
> 
> Tied to each other doesn't necessarily mean they should be handled by a
> common init script. busybox.mk can install S01klogd S02syslogd, and we
> keep this one daemon == one init script logic ?
> 
> Otherwise, assuming we stop using the common S01logging name, what
> would be the name of the init script installed by Busybox for its
> logging daemons ?

The problem here is Busybox. If we name each init script after the
corresponding daemon and select syslog-ng we will have both S01syslogd
and S01syslog-ng installed unless we have some configuration and/or
put some logic like this in busybox.mk:

ifeq ($(BR2_PACKAGE_SYSKLOGD)$(BR2_PACKAGE_RSYSLOG)$(BR2_PACKAGE_SYSLOG_NG),)
define BUSYBOX_INSTALL_LOGGING_SCRIPT
        if grep -q CONFIG_SYSLOGD=y $(@D)/.config; \
        then \
                $(INSTALL) -m 0755 -D package/busybox/S01syslogd \
                        $(TARGET_DIR)/etc/init.d/S01syslogd; \
        fi; \
        if grep -q CONFIG_KLOGD=y $(@D)/.config; \
        then \
                $(INSTALL) -m 0755 -D package/busybox/S02klogd \
                        $(TARGET_DIR)/etc/init.d/S02klogd; \
        fi
endef
endif

Is that OK for you?

-- 
Carlos Santos (Casantos) - DATACOM, P&D
?Marched towards the enemy, spear upright, armed with the certainty
that only the ignorant can have.? ? Epitaph of a volunteer

  reply	other threads:[~2018-11-02 21:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-07 11:45 [Buildroot] [PATCH v3 0/8] init scripts: rewrite S01logging Carlos Santos
2018-10-07 11:45 ` [Buildroot] [PATCH v3 1/8] busybox: update S01logging Carlos Santos
2018-10-08 15:14   ` Matthew Weber
2018-10-21 18:23   ` Arnout Vandecappelle
2018-10-07 11:45 ` [Buildroot] [PATCH v3 2/8] busybox: add logging configuration file Carlos Santos
2018-10-08 15:23   ` Matthew Weber
2018-10-21 18:27   ` Arnout Vandecappelle
2018-11-02 19:01     ` Carlos Santos
2018-10-07 11:46 ` [Buildroot] [PATCH v3 3/8] rsyslog: update S01logging Carlos Santos
2018-10-08 15:31   ` Matthew Weber
2018-10-07 11:46 ` [Buildroot] [PATCH v3 4/8] rsyslog: add logging configuration file Carlos Santos
2018-10-08 15:31   ` Matthew Weber
2018-10-07 11:46 ` [Buildroot] [PATCH v3 5/8] sysklogd: update S01logging Carlos Santos
2018-10-07 11:46 ` [Buildroot] [PATCH v3 6/8] sysklogd: add logging configuration file Carlos Santos
2018-10-07 11:46 ` [Buildroot] [PATCH v3 7/8] syslog-ng: update S01logging Carlos Santos
2018-10-07 11:46 ` [Buildroot] [PATCH v3 8/8] syslog-ng: add logging configuration file Carlos Santos
2018-10-11 15:09 ` [Buildroot] [PATCH v3 0/8] init scripts: rewrite S01logging Thomas Petazzoni
2018-10-12 11:50   ` Carlos Santos
2018-10-13 12:55     ` Thomas Petazzoni
2018-11-02 21:13       ` Carlos Santos [this message]
2018-11-02 21:25         ` Thomas Petazzoni
2018-11-02 22:30           ` Arnout Vandecappelle
2018-11-03 10:44             ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1901226171.9682.1541193229814.JavaMail.zimbra@datacom.com.br \
    --to=casantos@datacom.com.br \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox