syslogd logging

[Mike Dean]

Hi,

I'm trying to get system logging to work the way we'd like it to work for
our embedded Linux distribution.  I'm hoping to make it log to the buffer
and to the filesystem simultaneously, allowing our customers to use logread
or look through /var/log/, at their option, without changing any
configuration settings.  I can't seem to get Busybox to log to both
simultaneously.  Can this be configured somehow?

Additionally, I'd like to also be able to configure syslogd to log to a
remote syslog server without losing this local logging and buffering.  Is
this possible?


Thank you,
Mike Dean

System Engineer
md...@emacinc.com

EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901

http://www.emacinc.com/
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: xfs_fsr on Buffalo Linkstation

[Mike Dean]

Sorry, but he gave you terrible advice.  I have to wonder if he's ever used
XFS.

The xfs_fsr utility will exit once it has finished defragging the
filesystem.  What you really should do is this:

1. Run xfs_fsr -v  manually, and let it run until it finishes.  Run it one
more time, unless you still notice plenty of   extents: before: xx after:
xx   messages.  Once you stop seeing these, move on to the next step.
2. Set a cronjob to run DAILY to defrag the filesystem.  Not much
fragmentation should be added daily, so this step should complete very
quickly.

If you wait a full month between defrags, it will take significantly longer
to defrag and your overall performance will potentially suffer.  Keep in
mind that you need to ensure there's always enough free space on your drive
to make a duplicate of the largest file you keep on there.  Also, rules of
thumb:

If the drive is > 95%, it will fragment quickly.
If the drive is < 90% full, it shouldn't fragment very much.

So, try to keep it below 90% full; preferably, below 85% full.




On Sun, Oct 11, 2015 at 6:23 PM, Matthias Andersson <
matthias.anders...@pp1.inet.fi> wrote:

> Hello,
>
> Very well, I might schedule the job once a month.
>
> //Matthias
>
>
> On 11.10.2015 22.23, Hin-Tak Leung wrote:
>
>> I am curious about your plan of running it on a weekly basis.
>>
>> For a lightly used system, that seems a bit too frequent; for a system
>> that's constantly being used, that may be justifiable, but
>> then running it that frequently will probably (1) affect the performance
>> of the system for regular tasks (during that hour your system's,
>>   responsiveness will probably be bad, and that's a couple of hours
>> per week, not a small proportion of time), (2) increase tear-and-wear.
>>
>> In any case, I'd probably only do a defrag every few months,
>> or keep occupancy below a certain level (say, 60-70%) to keep
>> fragmentation low though... just my 2 cents.
>>
>> 
>> On Sun, 11/10/15, Matthias Andersson 
>> wrote:
>>
>>   Hello,
>>
>>   I own a Buffalo Linkstation Pro Quad 12 Tb which runs the
>>   busybox OS.
>>
>>   The NAS uses the XFS filesystem and provides the xfs_fsr
>>   defragmentation
>>   tool. The problem I've noticed is that the program doesn't
>>   obey the -t
>>   (seconds) parameter, I've tried xfs_fsr -t 3600 /dev/md2 and
>>   it runs
>>   over an hour. I then tried with 8 hours but it didn't stop
>>   there either.
>>   The -p 1 flag seems to work...
>>
>>   I'm trying to set up a cron-job to run xfs_fsr for a couple
>>   of hours on
>>   a weekly basis.
>>
>>   //Matthias Andersson
>>
>>
>>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

In the 2.6 and 3.x kernels, you annotate your init functions with the
__init macro, like so:

static int __init myinit( void )  { return 0; }

No more hoops are needed, but no fewer.  It's simple, and it works well for
the kernel.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Sat, Mar 22, 2014 at 5:47 AM, Lauri Kasanen cur...@operamail.com wrote:

 On Sat, Mar 22, 2014, at 1:57, Laurent Bercot wrote:
  On 21/03/2014 23:10, Cathey, Jim wrote:
   The only thing BB would need would be to isolate initialization
   into separate functions that would be grouped together by the
   linker.  (And an associated link control file.)  The usual demand-paged
   kernel will take care of the rest.
 
  Yes, that would definitely be the right approach. However, it conflicts
  with code organization, and thus, maintainability: currently, the code is
  sharded by functionality, which is sane and sound - but the linker would
  need the code to be sharded by type, init or non-init, which is exactly
  orthogonal to functionality. I'm not up to date with latest linkers, but
  unless you can annotate functions inside a single .c, it means that you
  now need to split every single functionality into at least two .c files.

 Slightly off tangent, but I remember reading a thesis on link time
 optimization for the 2.4 linux kernel.

 Among other things they managed to do was automatic recognition of init
 code, and moving such to its own section. It was quite interesting tech,
 no annotations needed; given the kernel already had some annotations,
 the tech merged the newly found init code to the annotated one. It could
 even detect parts that could not be annotated, because on some arch they
 would be called more than once - if your arch didn't, into the init
 section they went.

 So this could be done entirely in the linker, no busybox code needed.

 - Lauri

 --
 http://www.fastmail.fm - A fast, anti-spam email service.

 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

I agree completely.  I was just trying to show a simple example.


Mike Dean


On Fri, Mar 21, 2014 at 11:37 AM, Bernd Petrovitsch 
be...@petrovitsch.priv.at wrote:

 On Fre, 2014-03-21 at 10:50 -0500, Mike Dean wrote:
 []
  pseudo-code:

 A real patch would have been a step in the right direction.

 BTW the Linux kernel achieves that feature by annotating
 init-only-functions (and their data) explicitly so that these can end up
 in separate segments (which are freed eventually).

 Adding an additional shared lib costs elsewhere and the added code to
 load it at run-time explicitly too.
 The Linux kernel's way seems more usefull: Mark init-only functions as
 such, add linker magic so that that ends up in a separate segment (and
 thus separate pages which can be evicted on their own) ans it should
 work with any additional dlopen() 

 Bernd
 --
 Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
  LUGA : http://www.luga.at


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

You should've read the full thread.  The suggestion was to use dlopen() to
fix busybox keeping init code for *everything* in memory when it's not
needed, not just for a parser for an ntpd config file.

Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Fri, Mar 21, 2014 at 4:16 PM, Laurent Bercot ska-dietl...@skarnet.orgwrote:


  Are you seriously suggesting to add dlopen()ed libraries to busybox
 to offset the bloat of adding a config file parser to ntpd ?

  This is the exact kind of design that busybox is fighting.
  Please readhttp://busybox.net/FAQ.html#goals  and
 http://busybox.net/FAQ.html#tips_memory  , as well as
 http://en.wikipedia.org/wiki/KISS_principle .

 --
  Laurent


 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

Harald,

I'm curious.  You mentioned earlier that code is never freed from memory.
 If you're this concerned with bloat, why don't you fix your problem of
never deallocating the init code instead of worrying about some small
feature like this?  The Linux kernel does this; that's why you see the
message about Freeing xxKB of memory late in the boot process.  The freed
memory is the memory that was used by the initialization code.  This trick
isn't limited to kernelspace.  You can dynamically link libraries with init
code, and you can unlink them at runtime as well.  If you really want to
reduce bloat, you can take a page from the kernel devs and free all that
init code after the binary is up and running.  If you really are concerned
with bloat, that is.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Thu, Mar 20, 2014 at 10:11 AM, Harald Becker ra...@gmx.de wrote:

 Hi Denys !

 I don't know... I still feel compat is important.
 It means growth of user base.

 Compatibility with what? Busybox ntpd is not exactly modeled as
 upstream ntpd ... and it's the reason why I use BB ntpd, as I
 like it's simplicity, and dislike the upstreams complexity for a
 minimalistic operation.

 Most of features are bloat. CONFIG_FEATURE_FIND_DELETE
 is bloat - you can easily code it with -exec instead, right?

 Wow this is a completely unfair compare.

 You compare a feature which is heavily used by many users in
 many scripts and many command line usages, with a feature for a
 few admins not willing to read some config in scripts and create
 there command line correct.

 Think of this twice, before throwing in such kind of bloat. BB
 ntpd has all features required to do it's job. Every parameter
 can be set on command line. The request to have a config file is
 only from those not willing to read such config from compatible
 config file and place it in command line during daemon startup.

 Examples of how this compatibility can be achieved without adding
 the bloat has bean given in the thread. So if you add this kind
 of config it is not like other heavily used features (e.g. find
 -delete). It will add bloat for a few people not willing or able
 to get a single start script right and add a hand full of lines
 to read values from compatible config file on daemon startup.

 As this I consider it highly optional *AND* *NOT* part of a
 default build.

 Don't misunderstand. I don't want to block the feature, if you
 like to add it, but optional and only included if system
 creature explicitly selects it, and not part of a default build.

 - support for paranoid levels of compat (grep of NUL byte)

 IMO a paranoid level of compatibility, for those not willing to
 write a hand full of lines in a daemon startup script (a single
 script on a system). This is what I call this ntpd config file
 feature. So let it default to NO.

 --
 Harald
 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

Michael, Denys,

I'm sorry; it seems you don't understand.  I wasn't referring to depending
on gcc to do the linking for you, but rather doing it yourselves.  I'm
aware that you guys are used to depending on compilers, linkers and the
kernel to do the hard work for you, but really, it's not that tough to do.
 There's no reason you would have to load init code just because the
busybox process was started.  You load that on demand, not by default.
 That way, you don't waste memory by loading init code that has nothing to
do with the task busybox was launched to perform.  I can foresee your
complaints about the bloat this would introduce in determine what to load
and when, but therein lies another challenge: how to minimize this.
 Arguing until you're blue in the face about bloat as a knee jerk reaction
to requests for small features won't solve the problem for you, though;
you'll have to put some thought into the root cause to fix this issue.  The
kernel developers did, and look at how much better it has worked out for
them than it has for you.


Mike Dean



On Thu, Mar 20, 2014 at 12:30 PM, Denys Vlasenko
vda.li...@googlemail.comwrote:

 On Thu, Mar 20, 2014 at 5:28 PM, Mike Dean md...@emacinc.com wrote:
  I'm curious.  You mentioned earlier that code is never freed from memory.
  If you're this concerned with bloat, why don't you fix your problem of
 never
  deallocating the init code instead of worrying about some small feature
 like
  this?  The Linux kernel does this; that's why you see the message about
  Freeing xxKB of memory late in the boot process.  The freed memory is
 the
  memory that was used by the initialization code.  This trick isn't
 limited
  to kernelspace.  You can dynamically link libraries with init code, and
 you
  can unlink them at runtime as well.

 People who are concerned with size just link statically.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

The key word is, can, as in your statement, can be read back in again.
 If it's designed to only ever be loaded the first time it's executed after
boot, then there will be no reason to load it back in again when executed
after that first time.  If there's no need for the code, it won't be read
back in again.  You would have to specifically request it to be loaded upon
subsequent executions in order for it to be read in again.

This is why the kernel *does* successfully reduce RAM consumption by code
when it unloads the initialization code.  It just requires proper design.
 It's not some sort of kernel black magic which requires ring 0 or special
hardware support.  It's just good design.


Mike Dean



On Thu, Mar 20, 2014 at 1:08 PM, Denys Vlasenko vda.li...@googlemail.comwrote:

 On Thu, Mar 20, 2014 at 6:47 PM, Mike Dean md...@emacinc.com wrote:
  Michael, Denys,
 
  I'm sorry; it seems you don't understand.  I wasn't referring to
 depending
  on gcc to do the linking for you, but rather doing it yourselves.  I'm
 aware
  that you guys are used to depending on compilers, linkers and the kernel
 to
  do the hard work for you, but really, it's not that tough to do.
  There's no
  reason you would have to load init code just because the busybox process
 was
  started.  You load that on demand, not by default.

 In fact I don't understand what init code you are talking about.

  That way, you don't
  waste memory by loading init code that has nothing to do with the task
  busybox was launched to perform.

 The text pages  (pages contaning machine code) are read-only, and
 on MMU architectures they are shared.

 Meaning, in fact there is only one copy of each text page in RAM
 even if I run a thousand of busybox processes; and if there is
 memory pressure, kernel will find least used text pages
 and unmap them, freeing RAM for other use - because
 if they will be needed again, they can be read back
 from filesystem.

 IOW, for all intents and purposes RAM consumption by code
 can't be reduced by unloading parts of code by hand -
 kernel already does almost everything possible in that area.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

I think that adding this feature is an excellent idea.  I don't understand
where all the resistance is.  If there's code bloat from parsing a simple
config file, then perhaps Busybox isn't well designed.  I don't know, I
haven't worked with it's code; perhaps I'm just used to the Linux kernel's
code, but considering the number of utilities (including daemons) that
Busybox replaces, why doesn't it have generic library code for parsing
configuration files?  If you want to cast stones regarding bloating code
with configuration parsing, you should at least cast them in the right
direction.  If each individual tool that Busybox replaces has its own code
for parsing a configuration file (if it uses one), then *that* is the
problem, not the desire of users to have this feature.  I really don't
understand this resistance to meeting the needs of the end users.
 Personally, I think this type of resistance will only lead to people
eventually forking Busybox due to disagreements with the decisions made
regarding these types of features.  #ifdefs work very well for selectively
leaving out features like this, as I imagine you know, without leaving
behind and code bloat in binaries which have the feature disabled.  One of
the previous respondents to this chain suggested making it a menuconfig
option; that sounds very reasonable to me.

Looking back through this e-mail chain, it appears to be a 4:1 ratio so far
of people for this feature to people against.  If 4 people want it, and
only 1 person doesn't, doesn't that sound like a feature that *should* be
implemented?  It sure does to me.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 9:49 AM, Laszlo Papp lp...@kde.org wrote:

 That is the fourth solution I see now in a raw... after Yocto,
 Buildroot and OpenWrt...

 This is what I was referring to. It is inconsistent across projects. :)

 That being said, it seems that Harald is objecting to this heavily for
 some reason (may be miscommunication between us). Thereby, I will not
 insist on this. If the developers feel happier without that feature,
 let it be so.

 On Tue, Mar 18, 2014 at 2:32 PM, Cristian Ionescu-Idbohrn
 cristian.ionescu-idbo...@axis.com wrote:
  On Tue, 18 Mar 2014, Bryan Evenson wrote:
 
  How about a set of ntpd menuconfig options to build the command
  line?  We could configure the default ntpd settings at build time,
  it wouldn't add anything to the size of the final ntpd binary.
 
  How about using a resource file the initscript would source:
 
  ---[ rc-file ]---
  NTPD_OPT1='-f foo'
  NTPD_OPT2='-b bar'
  NTPD_OPT3=
  -
 
  ---[ initscript ]---
  #!/bin/sh
 
  . /path/to/rc-file
  ...
  command line to start ntpd $NTPD_OPT1 $NTPD_OPT2 $NTPD_OPT3
  ...
  
 
 
  Cheers,
 
  --
  Cristian
  ___
  busybox mailing list
  busybox@busybox.net
  http://lists.busybox.net/mailman/listinfo/busybox
 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Undo for vi

[Mike Dean]

I haven't worked with the code, but to me, it looks like:

1. it's stuffing a pointer to the first index into the passed in array into
q
2. it's replacing any newlines in the string with nulls
3. it's calling a colon() function to execute the command mode command
associated with the string that was passed in.

How about adding the feature of interpreting an interrupt (Control-C) as
the Esc key, just like vim does?  That's the feature I miss most, and one
of the reasons I switched our embedded Linux distro to using the full vim
instead of the Busybox one.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 9:51 AM, Jody Bruchon j...@jodybruchon.com wrote:

 On 3/18/2014 9:24 AM, Laszlo Papp wrote:

 Hi,

 do you plan to implement this feature any soon? It would be really
 useful. Currently, it is a bit difficult to do undo in certain
 scenarios when editing files on the embedded board.


 Out of an interest in seeing this feature, I'm looking at vi.c and find
 that the code is not terribly well commented. For example, variables 'p'
 and 'q' are used throughout the code but no explanation of what they are
 supposed to be for or what is happening with them exists.

 Could someone who has worked on this code give me an idea of what this
 block of code really does?

 -snip-

 #if ENABLE_FEATURE_VI_COLON
 {
 char *p, *q;
 int n = 0;

 while ((p = initial_cmds[n]) != NULL) {
 do {
 q = p;
 p = strchr(q, '\n');
 if (p)
 while (*p == '\n')
 *p++ = '\0';
 if (*q)
 colon(q);
 } while (p);
 free(initial_cmds[n]);
 initial_cmds[n] = NULL;
 n++;
 }
 }
 #endif

 -snip-


 Thanks in advance!
 -Jody Bruchon

 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

I just implemented such code for a project I'm working on, and I viewed it
as pretty trivial.

In any case, Busybox is king of going half way with features, so why not
make it just parse the config on startup and not worry about trapping
signals?  If you do wish to implement signal handling, then a well written
signal handler should make this easy; again, this boils down to the
existing design, since I'm sure Busybox already handles signals.  If the
struct you're passing a pointer to for your signal handler function
includes a list of function pointers to handle the event, then it should be
trivial to add; if not, then why bother?  The busybox version of vi doesn't
implement many features, so why should the ntpd config file parsing be
fully featured?


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 12:29 PM, Harald Becker ra...@gmx.de wrote:

 Hi Mike !

  If there's code bloat from parsing a simple config file, then
  perhaps Busybox isn't well designed.

 Same misunderstanding as Laszlo. It is not only parsing a simple
 config file. AFAIK libbb has functions to do this. The problem
 is, it makes no sense to blow up the BB binary size for only
 reading the peers address on daemon startup, without implementing
 that right and rereading/reconfiguring the running daemon when
 the configuration changes. And the code to handle this is more
 than trivial.

 In my eyes bloat to the binary - as other (simpler) changes to BB
 has bean neglected with the code size argument in the past. None
 of the mentioned changes improves operation of the current ntpd
 applet. Every parameter of ntpd can be given at the command line,
 reading the info from any (config) file is simple within scripts
 and does not increase BB binary size. So there would be extra BB
 code for no extra functionality, because there are a some people
 who don't get there calling scripts right (asking for extra binary
 code, for things simple to handle in scripting).

 Why don't you provide a script with common solution, we can add
 this to the contribution directory, for those who like to use it.

 --
 Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

Harald,

I would but I'm busy porting existing device drivers to Device Tree and
writing some new drivers.  Our last release used a kernel version that
didn't have Device Tree, so getting support for all the hardware on all of
our boards for this new kernel version is a substantial amount of work.

I will give you a use case where this feature makes sense, though: we build
embedded Linux images using Yocto, but unlike many people, we make our
images generic and add additional tools and a fully featured SDK.  We build
our distribution for customers who don't know how to do this themselves,
and don't have the inclination or approval to spend the time learning how
to.  We work hard to make things easy for them.  One of the stumbling
blocks our customers have had in the past is how to configure ntpd to use
their internal ntp servers.  Helping them with this usually results in
grumbling about it being overcomplicated to perform what should be such a
simple task.  Most of them have no idea how to write bash scripts, so this
task represents a real learning curve for them.  What makes this worse is
that they have no interest in learning bash; as soon as they finish this,
they go back to C++ (or C) to finish their work.

Now, personally, I've been writing software since the mid-1980's, so to me,
all software is much easier to write than it used to be, and the library
functions keep the code size small.  I personally don't see how this tiny
addition represents any significant increase to the size of the source tree
or the compiled binary.  I will tell you, however, that we'll just continue
use the full version of ntp for our upcoming distribution (we already made
the switch in our recipes) if this isn't added.  It's not worth the time or
effort for me to edit your code to add this.  I've simply been trying to
point out that catering to your users is the most important thing to do if
you want to keep them from jumping ship.  This may be one small portion of
Busybox, but it's one of about 20 that we've already replaced with full
versions for our upcoming release; the shortcomings in the busybox versions
aren't worth the savings in size in the days of GHz processors and 512MB+
RAM on small cheap embedded systems.  They're not even worth the savings on
our lowest end 200 MHz models; even those have a minimum of 128MB of RAM.
 I hope I'm not coming off as stubborn, annoying, or similar; that's not my
intention.  I'm just trying to get you to see things from the standpoints
of the people in this chain who've all clamored in favor of the feature.
 It honestly doesn't bother me either way, because as I said, I'll just use
the full version instead and not worry about it.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 1:35 PM, Harald Becker ra...@gmx.de wrote:

 Hi Mike !

 On 18-03-2014 12:52 Mike Dean md...@emacinc.com wrote:
 I just implemented such code for a project I'm working on, and I
 viewed it as pretty trivial.

 So why don't you provide an example for a patch to implement the
 function you request ... with full bloat check output and
 description of benefits ... then we can see if it makes sense to
 implement this.

 --
 Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

I couldn't agree more, Laszlo. 

Sent from my iPhone

 On Mar 18, 2014, at 2:44 PM, Laszlo Papp lp...@kde.org wrote:
 
 Sven, you totally missed the whole point of the thread in my opinion.
 At least three people expressed that it is about convenience, a useful
 one.
 
 On Tue, Mar 18, 2014 at 7:36 PM, Sven-Göran Bergh
 svengbergh-busy...@yahoo.com wrote:
 Hi Mike et.al,
 
 I have just finished reading through this thread and yet I have not seen
 any substantial explanation _why_ BB should include this feature.
 
 Both Harald and Cristian have suggested reasonable solutions for this.
 The concept of sourcing a config file from an initscript is common practice
 for most init systems whether it be sysvinit, systemd, or whatever. Sure
 they all differ in details, but the principal stays the same.
 
 So please explain what is so unique about your setup that this methods
 cannot be used. A flame war on how this could be done is not a satisfying
 answer to _why_. Convenience?
 
 Brgds
 /S-G
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

So you're telling me that a plain text script which takes more than 300 bytes 
is a better solution than an option that could be configured out?  But your 
full text option, enabled by default, takes less than 300 bytes I suppose?

Sent from my iPhone

 On Mar 18, 2014, at 2:49 PM, Michael Conrad mcon...@intellitree.com wrote:
 
 On 3/18/2014 3:09 PM, Mike Dean wrote:
 Helping them with this usually results in grumbling about it being 
 overcomplicated to perform what should be such a simple task.
 
 IMHO, the plethora of unix config file syntaxes are much harder to learn than 
 reading a quick manpage (or --help in this case) of the tool you want to run. 
  Where are they going to learn the syntax? Your documentation? Random 
 Internet documentation for the real ntpd?  The man page for the real ntp.conf 
 is 1700 lines long!
 
 On 3/18/2014 3:09 PM, Mike Dean wrote:
 I personally don't see how this tiny addition represents any significant 
 increase to the size of the source tree or the compiled binary.
 
 What syntax should be used?  the full ntpd syntax?  Should busybox emit 
 errors or warnings on directives it doesn't support?  I can't imagine you 
 could add this feature properly in less than 300 bytes, and that is 
 significant for busybox.
 
 On 3/18/2014 2:31 PM, Harald Becker wrote:
 ntpd -p `cat /etc/timeserver`
 
 I'm inclined to side with Harald that this is the best solution. Can't be 
 much simpler for the user than that...
 
 -Mike
 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

So it's difficult to provide and document a configuration file like this?

---
# Put your ntp nameservers here
#  Example:
# nameserver ntp.busybox.net
nameserver ntp.example.com
nameserver ntp2.example.com
---

I can see that we'll be using the full version of ntpd on our distro.
 You've fully convinced me that it's the most wise choice to make.

Thank you,

Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 3:00 PM, Michael Conrad mcon...@intellitree.comwrote:

 On 3/18/2014 3:54 PM, Mike Dean wrote:

 So you're telling me that a plain text script which takes more than 300
 bytes is a better solution than an option that could be configured out?
  But your full text option, enabled by default, takes less than 300 bytes I
 suppose?


 I'm not sure I follow.  Harald suggested adding 23 bytes to your existing
 script, and adds the convenience of a config file where there wasn't before.

 You could add that same minimal config file in C, and it would take a lot
 more than 23 bytes.

 Either way, the config file will be a thing specific to busybox ntpd and
 you will have the exact same documentation problem in teaching people how
 to use it, then they have learning about the -p command line switch.

 If you want to be compatible with a standard tool, and support ntp.conf,
 then you gain the popularly-available documentation, but add a significant
 amount of code.

 Neither way is really ideal.  So if you want to add a non-ideal solution,
 it should be done in a distro-specific script.

 -Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

On Tue, Mar 18, 2014 at 3:15 PM, Harald Becker ra...@gmx.de wrote:

 Hi Mike !

 ... We work hard to make things easy for them.  One of the
 stumbling blocks our customers have had in the past is how to
 configure ntpd to use their internal ntp servers.  Helping them
 with this usually results in grumbling about it being
 overcomplicated to perform what should be such a simple task.

 This clearly a failure of your system/distro NOT Busybox. Your
 build system shall provide a script to read address of your time
 server from a file and use this address when calling the ntpd
 daemon applet. So customers can be pointed to changing a line in
 a file.

 So the deficiency of your software can always be blamed on your software's
userbase?  Sounds like a winning philosophy.


 isn't added.  It's not worth the time or effort for me to edit
 your code to add this.  I've simply been trying to point out
 that catering to your users is the most important thing to do if
 you want to keep them from jumping ship.  This may be one small
 portion of Busybox, but it's one of about 20 that we've already
 replaced with full versions for our upcoming release;

 You are always free to replace Busybox functionality with full
 versions. Busybox is neither a system nor a build system nor a
 distro. It is a collection of smaller and simpler counterparts
 than the usual full GNU and other utilities (Beside that there
 exist other alternatives). The intention here is to have SMALL
 binaries using the KISS (keep it simple and small) principle.
 Adding unnecessary config file functionality without other
 benefit violates this KISS principle. Everything can be achieved
 with setting up your right script ... not by the customer, by
 the system/distro maintainer.

 shortcomings in the busybox versions aren't worth the savings in
 size in the days of GHz processors and 512MB+ RAM on small cheap
 embedded systems.  They're not even worth the savings on our
 lowest end 200 MHz models; even those have a minimum of 128MB of
 RAM.

 I know ... 640 kByte RAM ought to be enough for everybody ???

 ... think of there are still more small systems out there, e.g.
 small router boxes with very limited resources. Busybox shall
 give small and simple tools for most users not a versatile system
 for your customers.

 If you use Busybox, make it versatile to your customers by
 creating right control scripts and system setups including
 full documentation, and not pointing them around to collect
 information from other places, e.g. up to date version of
 Busybox.html from build (not from Web-Page).

  I'm just trying to get you to see things from the standpoints
  of the people in this chain who've all clamored in favor of
  the feature.

 I don't say you are wrong, but you are at the wrong place to
 bother. Busybox is not a complete and easy to use system, it is
 just a collection of small and simple alternatives of other
 tools. Use it, when you like and build your system with it, but
 don't add useless code to main binary (for thing easily being
 achieved by other ways).

  ... I'll just use the full version instead and not worry about
  it.

 Fine, you are always free to do this. Depending on kind of system
 I replace from 30 to 75% of Busybox with full or alternative
 versions, using Busybox versions as small and fast scripting
 versions.

 --
 Harald


My choice to switch stems not from having any difficulty scripting an
alternative, but rather from the lack of trust I have in the busybox
version given my opinion of the decision made by the developers regarding
something that should be a clear cut easy choice.  In my job, when the
customers want something, you find a way to give it to them.  If adding the
feature outright would bloat the system, you make it a configurable choice
so that it won't add bloat where that bloat is unwelcome, but will aid
those who value the convenience more than the space savings.  You already
have the means to do this easily, so why not do it?

When was the last time this mailing list received so many e-mails in one
day?  Especially about just one topic?  That alone should have been a red
flag to you that the users of your software feel that this is important.
 Religious zealotry about a development concept has never led to good
products; engineering (and any software development) is all about trade
offs.  Your unyielding zealotry, instead of facing the challenge of make
the trade off to satisfy the needs of your userbase, combined with you
blaming others for your own shortcomings, is what inspired me to make the
switch.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

[Mike Dean]

Actually, I didn't come to the list to ask for the feature.  Someone else
came here to ask for it; I just seconded this person.  You, much like
Harald, are blaming the deficiencies of your design decisions on your
users.  The haughty attitude, from our standpoint, comes from you, not from
us.  To start with, we don't design the tools; we are in the business of
designing hardware, writing device drivers, contributing to the Linux
kernel and getting Linux up and running on our hardware; then, we customize
the embedded Linux distro until everything is sane.  Then we add features
that we know our customers want.  It is this last part that you're missing
the point of.  We pick the sane tools, and configure them properly.  When a
tool isn't sane, we find an alternative that is.  That's why I have now
chosen to use the normal ntpd over the busybox implementation.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 4:05 PM, Laurent Bercot ska-dietl...@skarnet.orgwrote:

 On 18/03/2014 20:29, Mike Dean wrote:

 So the deficiency of your software can always be blamed on your
 software's userbase?  Sounds like a winning philosophy.


  The fact that you still think using command-line arguments instead of
 a config file is a deficiency shows that you are missing the point.
 Not having a config file when a config file is not needed is not a
 deficiency, it's a design decision - and a pretty sound one.
  The fact that your tools apparently cannot easily work with command-line
 arguments is not Busybox's problem, it's a severe misdesign of your tools.
 Command-line arguments are the very basis of the Unix API; you've been
 working with it since the 80s, you should know that by now. :P

  If you want to extend ntpd's interface for your users and add a config
 file, you're free to do so. It's not hard. But, again, this is a job for
 *you* as an integrator: do not try to shift the burden of doing it to
 upstream, because it's not where it belongs. You are of course free to
 contribute and submit patches: maybe they'll be accepted, maybe not.
 But coming to the list asking people to do your job for you and getting
 all haughty when your request is politely denied probably isn't the best
 way to get things done.

 --
  Laurent


 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Running a script every second

[Mike Dean]

Or, you could use a Xenomai-enabled Linux kernel.  That way, Linux
*is* realtime,
so you will be guaranteed to get scheduled for execution every second.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Thu, Mar 6, 2014 at 1:34 PM, Michael Conrad mcon...@intellitree.comwrote:

 I know this borders on bike-shedding, but if you really want to run
 something exactly 60 times per elapsed minute you need to compare calls to
 clock_gettime(CLOCK_MONOTONIC).  Nothing else will work reliably in all
 cases, and certainly not signals.  (if the system is lagged significantly,
 two signals can be merged into one)

 I'm not aware of any way to call clock_gettime from a shell script, but
 Perl can do it.  If you don't have perl and you still want it to be a
 script for ease-of-maintenance, I would recommend:

   1. write a very small C program that calls clock_gettime() for an
 initial timestamp, writes \n on STDOUT, increment timestamp by exactly 1
 second, calls clock_gettime(), and then usleep()s for the difference
 between clock_gettime and timestamp, if greater than 0.

   2. write a script that performs ./c_prog | while read; do something();
 done

 No special file descriptors, process IDs, signals or other mess, and
 guaranteed one iteration of the script per every elapsed second (but no
 guarantee that the execution occurs during that second.  Linux isn't
 realtime, afterall)

 -Mike


 On 3/6/2014 9:25 AM, Yan Seiner wrote:


 On 03/05/2014 10:49 PM, Harald Becker wrote:

 Hi Yan !

 On 05-03-2014 09:14 Yan Seiner y...@seiner.com wrote:

 I am trying to run a script every second.

 Beside what Laurent told about using sleep, etc.

  first script (the one that does the work)

 trap 'update' HUP
 mknod /tmp/dummyfifo p
 while true; do
  read  /tmp/dummyfifo  /dev/null 21
 done
 The problem is that the 'read' generates a
 /usr/bin/update: line 1: can't open /tmp/dummyfifo: Interrupted
 system call

 The reason for this is you create your pipe once, but open it
 again at every iteration of the loop.

 Try the following:

 mknod /tmp/dummyfifo p
 exec 0/tmp/dummyfifo 1/dev/null 21
 while true; do
 read
 done

 This opens the fifo once and assigns it for stdin. After that it
 stays open until the first script is terminated in any way.

 In addition stdout *AND* stderr are redirected to /dev/null for
 all following commands in the script, so you need to redirect to
 any file or tty when you want do display something.


 Thanks!

 I like it.  My solution leaves 'cat' processes behind if the script gets
 killed.  Usually not a problem since it's only invoked at boot.

 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox


 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: busybox udhcpc client

[Mike Dean]

Denys,

Okay great, thank you.  I'll look for that default.

Thanks,

Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Wed, Feb 19, 2014 at 8:34 AM, Denys Vlasenko vda.li...@googlemail.comwrote:

 On Wed, Feb 19, 2014 at 2:30 AM, Mike Dean md...@emacinc.com wrote:
  Thank you for the prompt response on this.  I am looking into modifying
 the
  code for the busybox version of ifup to add the -s option and will see
 if I
  can make it work for my application.

 -s option has a default. If you install your script in the default
 location,
 you need no pass -s SCRIPT to udhcpc.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: busybox udhcpc client

[Mike Dean]

Rich,

Thank you for the prompt response on this.  I am looking into modifying the
code for the busybox version of ifup to add the -s option and will see if I
can make it work for my application.

Thank you,

Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Fri, Feb 14, 2014 at 10:46 PM, Rich Felker dal...@aerifal.cx wrote:

 On Fri, Feb 14, 2014 at 07:06:50PM -0600, Mike Dean wrote:
  Hi,
 
  Does anyone know if there's a way I can find out when udhcpc gets a new
 IP
  address assigned via DHCP?  I would like to trigger a script on this
 event,
  but I can't find any files to watch or any hooks I can use to trigger my
  script.  Any help with this would be greatly appreciated.

 See udhcpc --help. There's a script option (-s) which controls what's
 executed on dhcp state changes. Without any script, udhcpc will not
 even change the interface ip; it just makes the dhcp requests to the
 server but leaves alone the local network config.

 Rich

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

busybox udhcpc client

[Mike Dean]

Hi,

Does anyone know if there's a way I can find out when udhcpc gets a new IP
address assigned via DHCP?  I would like to trigger a script on this event,
but I can't find any files to watch or any hooks I can use to trigger my
script.  Any help with this would be greatly appreciated.

Thanks,
Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox