On Monday 20 August 2001 10:33, Federico Sevilla III wrote:
> On Mon, 20 Aug 2001 at 10:15, Raymund dos Remedios wrote:
> > You might want to try directing std-out of the cron output to
> > /dev/null. On the Vixie cron, the std-err will still get mailed to
> > the crontab owner unless you override the MAILTO.
>
> While true this is only necessary when running programs that will spit out
> known messages regularly. sync shouldn't send anything to stderr, and if
> it does, you'd sure like to know, right?
That is a valid point. That is why I phrased my sentence the way I did. I
know that the sync does not generate a standard out. However, the suggestion
I gave had to do with managing growing logs from a cron that fired every
second (or so I thought).
As far as I recalled, the cron would actually send an e-mail and not a log.
However, without further checking, I figured that, as has happened to I'm
sure everyone before, myself included, we forget certain options and a little
friendly jog of the memory might help. I do hope it served it's purpose. If
not , IMHO, knowing that you can re-direct the output of a cron job is still
a valuable piece of trivia.
>
> > http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v
> >1.3/gen-optim.html ... talks about bdflush and buffermem.
>
> I looked at the documentation, and just thought I'd let the list know that
> the optimizations recommended are meant to "speed things up" by doing such
> things as allowing 100% of the buffer to be dirty before flushing them
> onto disk.
>
> This has absolutely nothing to do with making bdflush act as a "poor man's
> UPS", and in fact increase the chances of data loss as data fills your
> buffer. Imagine if 99% of your buffer is full and the power dies out on
> you.
It is interesting how you can read a document see it as one thing and have
someone read it totally different than you. Who's to say who's right? :-)
At any rate, I believe, contrary to your opinion, it does have something to
do with the "poor man's UPS". In the first place, the purpose of the bdflush
daemon to "flush" what is in the memory buffers to disk. Isn't that the
objective of the "poor man's UPS"? Hmmm... in fact, the man page of bdflush
states "bdflush - kernel daemon to flush dirty buffers back to disk."
Furthermore, as with other unixes (and unix like OS's), there is usually a
daemon that takes care of flushing buffers to disk. I believe that was the
objective of the "sync cron entry". Infact, the man page further states that
when "called by a user without superuser priveledges, it calls flush() and
sync() and then exits". Which by the way if you check the sync man page,
is exactly what the sync command does too, to wit, "The sync program does
nothing but exercise the sync(2) system call".
The bdflush implementation (or similar daemons in other OS's) takes the "sync
cron entry" to another level. While you can make the bdflush perform like
the "sync cron entry", it's objective was to allow the person who is tuning
the OS the flexibility of defining the criteria for when a "clean up" would
occur. The flexibility involved other criteria that were not just time
constrained. I figured I would refer the reader to the linuxdoc page for
what I felt was a good write-up of the options. My sincere apologies if that
was taken to mean otherwise...
Believe me, the flexibility is a good thing. Sometimes, you may agree to
live with a potential 30 second loss of transactions as long as file
integrity is assured (as with reiserfs), and over-all system performance
does not suffer. But, hey, on a standalone workstation, frequent flushes
probably won't even make a dent.
Without going into details, I've had experiences where that ability allowed
me to do things with database servers on small machines running multiple
concurrent users (ergo lots of dirty buffers), that would otherwise have
required an upgrade, when money was not necessarily forthcoming. But, that's
like ripley's, right?, "Believe it or not!" :-)
>
> My initial message about bdflush was meant to do something similar to
> running sync every second, by telling bdflush to flush ordinary data
> buffers onto disk at a maximum of 100 jiffies (1 second). IMHO this seems
> to be a "cleaner" implementation, compared to running sync every second.
> If I am wrong, someone please help enlighten me. I've sent this "bdflush
> vs sync" recommendation to the XFS list and haven't gotten any "sync is
> better" responses.
>
> I also wonder why RedHat needs the _network_ to be restarted for bdflush
> optimizations to take place. Aside from the fact that I don't see what
> bdflush has to do with the network, this sure sounds Micro$ofty.
Hmmm ... are we accusing RedHat of being Microsoft? ;-)
>
> On my system (running Debian GNU/Linux) I have a script bdflush in
> /etc/rc.boot. This gets run at boot time, and is where I put my customized
> boot scripts. To run my scripts without rebooting, I just
> "/etc/rc.boot/bdflush". This, in turn, uses the sysctl file
> /proc/sys/vm/bdflush to reconfigure the bdflush daemon on the fly, which
> is how things should be done anyway. :)
>
> > * * * * * root /bin/sync
> > ^^^^
>
> Makes sure /bin/sync is run by the root user. :)
>
Now, I'm lost. While sync can be run by anybody, why would you want to do
that? I am assuming that the crontab mentioned is the root crontab? And if
it was not a root crontab, I don't know that it would be a good idea to
simply allow a user to define "root" to fire up a system daemon that should
only really be run by a root user simply by prepending "root" to the command?
Could I do a * * * * * root passwd .... type of deal? I guess as I've often
done in the past, I may have missed the boat, err ... the point. My
apologies again if that is the case. :-)
Peace!
P.S. I made a simple test. I did a * * * * * root /sbin/sync and my mailbox
automagically filled up with "Cron <root@...> /bin/sync". Opening up the
e-mail, it said "/bin/sh: root: command not found". Go figure ;->
_
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
To subscribe to the Linux Newbies' List: send "subscribe" in the body to
[EMAIL PROTECTED]
