nvdimm.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: "Qi, Fuli" <qi.fuli@jp.fujitsu.com>
Cc: linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [RFC PATCH v4] ndctl: monitor: add ndctl monitor daemon
Date: Fri, 30 Mar 2018 09:34:37 -0700	[thread overview]
Message-ID: <CAPcyv4gVxw8OCnm0PsbC0PrBxpUBupvkK=w4L4p=gWQRsk4ouQ@mail.gmail.com> (raw)
In-Reply-To: <0DEDF3B159719A448A49EF0E7B11E3222764B6A2@g01jpexmbkw01>

On Fri, Mar 30, 2018 at 12:34 AM, Qi, Fuli <qi.fuli@jp.fujitsu.com> wrote:
>> >> > In this implemention, when a ndctl monitor starts with [--daemon]
>> >> > option, all the arguments will be saved into a temp file named as
>> >> > daemon-name and placed under /etc/sysconfig/ndctl/ directory. The
>> >> > temp file would be used as an EnvironmentFile by systemd, and it
>> >> > would be deleted automatically when the systemd service is stopped.
>> >>
>> >> The monitors started by hand should be kept separate from the
>> >> monitors started by systemd. The default monitor started by systemd
>> >> should get its configuration from /etc/ndctl.conf, and we should
>> >> otherwise have a --conf-file option to the monitor to override the
>> >> default configuration. Any other monitors started outside of the
>> >> systemd should remain independent.
>> >>
>> >
>> > I prefer to add an EnvironmentFile like /etc/sysconfig/ndctl/monitor
>> > to systemd rather than add a configuration file. According to [1],
>> > environment variable substitution is supported in systemd.service, so
>> > we can define the variables through
>> "EnvironmentFile=/etc/sysconfig/ndctl/monitor".
>> > In this fashion, we do not need to add any extra codes to parse the configuration
>> file.
>> >
>> > In this case, [--conf-file] option is not necessary either.
>> > According to [2], sytemd units can be instantiated from a template
>> > file, thus we only need to add a template unit file in advance.
>> > If user wants to run multiple monitors with different configurations,
>> > they can differentiate them by adding multiple EnvironmentFiles, like
>> /etc/sysconfig/ndctl/<monitor1...n>.
>> > Then the monitors can be started by command like "# systemctl start
>> > ndctl-monitor@<monitor1...n>.service".
>> >
>> > When the monitors started by hand, it will do not need any
>> > configuration files, because we can add options and parameters directly.
>> >
>> > [1]https://www.freedesktop.org/software/systemd/man/systemd.service.ht
>> > ml
>> > [2]https://www.freedesktop.org/software/systemd/man/systemd.unit.html
>> This seems to needlessly tie ndctl to systemd, it should be able to operate without
>> requiring systemd. I expect it would be straightforward to copy the configuration file
>> implementation from git.
> Would you like to explain why it should be able to operate without requiring systemd?

systemd is not universally available in all distributions and it is
useful to have custom configuration files for manually started

Another consideration is that a sub-set of monitoring activities can
be done without root privileges. It would be unforunate if a user
could not specify changes to the configuration because those files are
root-only and owned by systemd.

> The reason we want to add the configuration file is that when starting the monitors by systemd,
> options and arguments cannot be passed by systemd.
> When we start monitors by using "# ndctl monitor" command, we do not need any
> configuration files, because options and arguments can be added directly.
> Furthermore, if we choose configuration file implementation, we may encounter the following problem.
> If we start the monitor with command like "# ndctl monitor --dimm nmem1 --daemon --conf-file /etc/ndctl.conf",
> when the variable of dimm in configuration file is not the same as the argument of [--dimm] option,
> which argument should the filter_dimm() refer to?

The command line option should union with the configuration file for
filtering options. I.e. if the config file says to monitor nmem0 and
the command line says to monitor nmem1 then the tool should monitor
both. If there are other settings the might be in conflict then
command line should override the configuration file.

This matches the policy of most daemons that I have encountered in Linux.
Linux-nvdimm mailing list

  reply	other threads:[~2018-03-30 16:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13 11:33 [RFC PATCH v4] ndctl: monitor: add ndctl monitor daemon QI Fuli
2018-03-14 18:19 ` Dan Williams
2018-03-15 10:41   ` Qi, Fuli
2018-03-16  1:03     ` Dan Williams
2018-03-16  7:33       ` Yasunori Goto
2018-03-16 10:01         ` Qi, Fuli
2018-03-16  6:55   ` Yasunori Goto
2018-03-16 13:28     ` Dan Williams
2018-03-17  0:23       ` Yasunori Goto
2018-03-19 11:27   ` Qi, Fuli
2018-03-19 14:27     ` Dan Williams
2018-03-20  1:03       ` Qi, Fuli
2018-03-29 10:02   ` Qi, Fuli
2018-03-29 22:59     ` Dan Williams
2018-03-30  7:34       ` Qi, Fuli
2018-03-30 16:34         ` Dan Williams [this message]
2018-04-02  0:10           ` Qi, Fuli
2018-04-05 23:17       ` Qi, Fuli
2018-04-06 19:02         ` Dan Williams
2018-04-09  8:38           ` Qi, Fuli
2018-04-09 17:45             ` Dan Williams
2018-04-10  2:15               ` Qi, Fuli
2018-04-10  3:06               ` Verma, Vishal L
2018-04-04 14:28     ` Jeff Moyer
2018-04-05 21:08       ` Qi, Fuli

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:

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

  git send-email \
    --in-reply-to='CAPcyv4gVxw8OCnm0PsbC0PrBxpUBupvkK=w4L4p=gWQRsk4ouQ@mail.gmail.com' \
    --to=dan.j.williams@intel.com \
    --cc=linux-nvdimm@lists.01.org \
    --cc=qi.fuli@jp.fujitsu.com \


* 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;
as well as URLs for NNTP newsgroup(s).