On Mon, 20 Aug 2001 at 16:30, Raymund dos Remedios wrote:
> As far as I recalled, the cron would actually send an e-mail and not a log.
I'm sure this can be configured somewhere, but on my system, and it seems
on Juan Miguel's as well, it does both. It will send syslog a signal
whenever it runs (and you'll find this in your logs), and will send the
configured user an e-mail if the command returns some message on stderr.
> 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? :-)
The document did explain bdflush in little detail, but because it focused
on optimization for speed I did not see its relevance to the discussion
about implementing a "poor man's UPS". I was assuming everyone else in the
discussion knew what bdflush did, and if he/she didn't, could follow my
numerous links to the /usr/src/linux/Documentation/filesystems/proc.txt
file, which I believe, is one of the authoritative sources for information
on the parameters in the buffermem and bdflush sysctls.
But with your objective being to "explain" the bdflush, then yes, your
link had absolutely everythign to do with the thread. :)
> Infact, the man page further states that when "called by a user
> without superuser priveledges, it calls flush() and sync() and then
> exits".
Okay, now this is what I was wanting to talk about. Thank you. :)
Checked the sync(2) manpage and "sync - commit buffer cache to disk".
There is no manpage for flush(). So I'm wondering, what's the difference
between flushing a data buffer, and commiting a buffer cache to disk (as
with sync)?
I expect that the bdflush daemon takes care of regularly flush()ing data
depending on the configuration, which as per my example, did so every 100
jiffies at the least. Is this in any way lacking compared to flush() +
sync()? I am interested because on the server it is important for us to
get data to disk right away, without mounting the filesystems
synchronously which would kill performance.
> 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!" :-)
I do believe optimization has its pros and cons. On the upside you get a
free upgrade, and wipe the competition away. On the downside, power
outages or some other unforseen system halt with dirty buffers all over
will wipe out whatever data was in those buffers.
> Hmmm ... are we accusing RedHat of being Microsoft? ;-)
In a way yes, in a way no. You know why not, and you can imagine why yes.
I don't want to get myself into major flame wars, but anyone wanting to
fill in our imaginations for "yes" can do so with my blessing. ;>
> Now, I'm lost. While sync can be run by anybody, why would you want to
> do that?
I have absolutely no idea. I just explained what that "root" there was
for. :)
> 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?
Cron does not, and should not, allow this. It allows the root crontab(s)
to run things as non-root users, though. :)
> 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 ;->
Interesting. This does NOT happen on my system. I cannot tell what "kind"
of cron, I'm running as there is no information in the package about this.
It's version 3.0pl1,though. And I have lines such as:
30 2 * * * root /usr/local/sbin/samba.backup daily
That don't generate error message e-mails unless samba.backup spews
anything up, which I need to know, hence the absence of the redirection to
/dev/null. :)
--> Jijo
--
Federico Sevilla III :: [EMAIL PROTECTED]
Network Administrator :: The Leather Collection, Inc.
GnuPG Key: <http://jijo.leathercollection.ph/jijo.gpg>
_
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]
