Sponsored Content
Top Forums UNIX for Advanced & Expert Users Inter-process communication:pipes,doors,etc. Post 302159273 by adderek on Thursday 17th of January 2008 09:25:24 AM
Old 01-17-2008
Question Inter-process communication:pipes,doors,etc.

Hi,
I am thinking about writing a log daemon for a multi-processed ksh application (yes - I know that high-level language would be a better option).
My question is as follows:
If many processes (many scripts) will try writing to a single log file:
print "message" > common.log
Will it work or is there a risk of collision between them?
If there is such a risk then is it better to use named pipes or doors for such logging system?
And maybe there is some alternative?
 

10 More Discussions You Might Find Interesting

1. Programming

Inter Process Communication

unix IPC i would like to know the method of usage of semaphores on shared memory segments the topic seems very difficult to understand mainly when difrent proceses communicate instantly and how do i avaoid deadlock situation (2 Replies)
Discussion started by: kamathanil
2 Replies

2. Programming

signal in process communication

signal in process communication: I 'm a example in sun_unix that signal in process communication It's here down but I only have freebsd in my machine. how can i do the same in freebsd eg: #include <stdio.h> #include <signal.h> #include <unistd.h> int main( void ){ void... (2 Replies)
Discussion started by: a9711
2 Replies

3. UNIX for Advanced & Expert Users

Interprocess communication using pipes and fork

I'm very worried. I have an assignment that is due in 3 weeks, and also tute exercises which I can't seem to understand and work out. Okay, the question: The parent process will convert the command arguments into integer values using atoi() and store them into an integer array which you will... (2 Replies)
Discussion started by: scmay
2 Replies

4. HP-UX

Inter Process File Handling Problem

Hi All, i am running a oracle procedure which writes a file . The same file is picked up by another script which runs in a cron after every 5 minutes. Now the problem is that sometimes my script picks up a file while the procedure is still writing data in the file. is there is any way i... (4 Replies)
Discussion started by: saurabhjain
4 Replies

5. Programming

Problem with signals - 3 process communication

Hello, I would like to ask you for a little help with program I'm working on. I have problems with signals and synchronizing processes (I'm quite new to this part of programming). Process "parent" creates new child process "child1" and this process creates new child process "child2". The... (2 Replies)
Discussion started by: Nightwright
2 Replies

6. Programming

C program using IPC (inter process communication)

i want to write a C chat program that communicates over IPC(inter process communication), that could be run using 2 seperate terminal windows within the same computer. so that wat u type in one terminal window , should appear on the other and vice versa... could some one please help me with the... (2 Replies)
Discussion started by: localp
2 Replies

7. Programming

help with write-read locks inter-process

I need help!Many Thanks! Now,I try to manage the shared memory inter-process . Inevitably,I have to deal with the synchronous. I know the pthread_rwlock in posix,and I compile ,then run successfully in Red Hat Enterprise 4. I have a doubt about whether the Posix supports the system such as... (1 Reply)
Discussion started by: weizh
1 Replies

8. OS X (Apple)

Inter-shell communication

If I open two bash shells and telnet from Shell 2 to a remote server (on the Net), is there a way to direct input from Shell 1 to the telnet shell? The telnet shell is a limited environment with a specific command set. I want to direct commands from Shell 1 and, if possible, put 1-second... (2 Replies)
Discussion started by: xinUoG
2 Replies

9. Programming

please help a problem in client-server ipc message 2 pipes communication simple example

I want to have a message send & receive through 2 half-duplex pipes Flow of data top half pipe stdin--->parent(client) fd1--->pipe1-->child(server) fd1 bottom half pipe child(server) fd2---->pipe2--->parent(client) fd2--->stdout I need to have boundary structed message... (1 Reply)
Discussion started by: ouou
1 Replies

10. Programming

Application with communication between process

Hello I would like to create an application with communication between processes, application tightly coupled, have you please an idea about an API or a tool that allows me to generate such application? Thank you so much (11 Replies)
Discussion started by: chercheur857
11 Replies
nfslogd(1M)															       nfslogd(1M)

NAME
nfslogd - nfs logging daemon SYNOPSIS
DESCRIPTION
The daemon provides operational logging to the HP-UX NFS server. It is the daemon's job to generate the activity log by analyzing RPC operations processed by the NFS server. The log will only be generated for file systems exported with logging enabled. This is specified at file system export time by means of the share_nfs(1M) command. Each record in the log file includes a time stamp, the IP address (or hostname if it can be resolved) of the client system, the file or directory name the operation was performed on, and the type of operation. In the basic format, the operation can either be an input (i) or output (o) operation. The basic format of the NFS server log is compati- ble with the log format generated by the Washington University daemon. The log format can be extended to include directory modification operations, such as and The extended format is not compatible with the Washington University daemon format. See nfslog.conf(4) for details. The NFS server logging mechanism is divided in two phases. The first phase is performed by the NFS kernel module, which records raw RPC requests and their results in work buffers backed by permanent storage. The location of the work buffers is specified in the file. Refer to nfslog.conf(4) for more information. The second phase involves the user-level daemon, which periodically reads the work buffers, interprets the raw RPC information, groups related RPC operations into single transaction records, and generates the output log. The daemon then sleeps waiting for more information to be logged to the work buffers. The amount of time that the daemon sleeps can be configured by modifying the parameter in The work buf- fers are intended for internal consumption of the daemon. NFS operations use file handles as arguments instead of path names. For this reason the daemon needs to maintain a database of file handle to path mappings in order to log the path name associated with an operation instead of the corresponding file handle. A file handle entry is added to the database when a client performs a lookup or other NFS operation that returns a file handle to the client. Once an NFS client obtains a file handle from a server, it can hold on to it for an indefinite time, and later use it as an argument for an NFS operation on the file or directory. The NFS client can use the file handle even after the server reboots. Because the database needs to survive server reboots, it is backed by permanent storage. The location of the database is specified by the parameter in the file. This database is intended for the internal use of the daemon. In order to keep the size of the file handle mapping database manageable, prunes the database periodically. It removes file handle entries that have not been accessed in more than a specified amount of time. The configurable parameter in specifies the interval length between successive runs of the pruning process. A file handle record will be removed if it has not been used since the last time the pruning process was executed. Pruning of the database can effectively be disabled by setting the as high as When pruning is enabled, there is always a risk that a client may have held on to a file handle longer than the and perform an NFS opera- tion on the file handle after the matching record in the mapping database had been removed. In such case, the pathname for the file handle will not be resolved, and the log will include the file handle instead of the pathname. There are various configurable parameters that affect the behavior of the daemon. These parameters are found in and are described below: Sets the file mode for the log files, work buffer files and file handle mapping database. Specifies the minimum size, in bytes, that the buffer file must reach before processing the work information and writing to the log file. The value of must be between 1 and the maximum file size that is supported by the file system where the buffer file resides. Specifies the amount of time, in seconds, the daemon should sleep while waiting for more information to be placed in the buffer file. also determines how often the configuration file will be reread. The value of must be between 1 and The periodically cycles its logs. specifies the maximum number of log files to save. When is reached, the oldest files will be over- written as new log files are created. These files will be saved with a numbered extension, beginning with The oldest file will have the highest numbered extension up to the value configured for The value of must be between 1 and Specifies how often, in hours, the log files are cycled. is used to insure that the log files do not get too large. The value of must be between 1 and Specifies the time interval, in seconds, between updates of the records in the file handle to path mapping tables. Instead of updating the of a record each time that record is accessed, it is only updated if it has aged based on this parameter. The record access time is used by the pruning routine to determine whether the record should be removed from the database. The value of this parameter must be between 1 and Specifies when a database record times out, in hours. If the time that elapsed since the record was last accessed is greater than then the record can be pruned from the database. The default value for is 168 hours (7 days). The value of must be between 1 and EXIT STATUS
The following exit values are returned: Daemon started successfully. Daemon failed to start. FILES
system record of logged file systems NFS server logging configuration file default parameters for AUTHOR
was developed by Sun Microsystems, Inc. SEE ALSO
share_nfs(1M), nfslog.conf(4). nfslogd(1M)
All times are GMT -4. The time now is 09:25 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy