suaveant has asked for the wisdom of the Perl Monks concerning the following question:

Ok... at my company we have a legacy system that runs on solaris. It is 99 percent Perl except for a C app called mtimestamp which basically is a log daemon.

The system used a pipe and SysV streams to have one point of entry but keep track of which process sent the message in (my knowledge of this is minimal, please forgive me if I am not explaining it exactly right).

Our people have been having issues getting sysV streams to work on Linux, and really we figure there is probably a better solution.

What happens is this... the C daemon is started with some information about the application it is logging (a process manager). When jobs are started, they fork off and maintain the pipe, sending ininitialization info about who they are, which the logger stores. Somehow sysV streams can distinguish between which process is sending over the pipe, even though it is all just forked versions of the same copy. From that point on, anything from that subprocess' STDOUT and STDERR (and programs run in backticks, etc) is redirected to the logger and in mtimestamp is prefixed with a timestamp and the identifier the initializer set.

I am exploring ways of implementing this all in perl without sysV streams so that we can port it to Linux easier and to bring the codebase into line with the rest of the project.

So far I verified that UDP sockets would work alright, and of course TCP could be used... new sockets just have to be created at initialization, no big deal.

One thing I had tried was UDP over UNIX sockets, but I couldn't figure out a way to distinguish senders. The peerpath blows up IO::Socket::UNIX in this case...

Does anyone know if sender can be distinguished somehow in UDP UNIX domain sockets?

Does anyone have any other suggestions? Keep in mind that programs run in backticks and system calls also have to be redirected with on the same pipe.

                - Ant
                - Some of my best work - (1 2 3)

  • Comment on Porting a system 5 streams app to linux

Replies are listed 'Best First'.
Re: Porting a system 5 streams app to linux
by devnul (Monk) on Apr 29, 2005 at 00:10 UTC
    I'm a bit confused by what you are asking here....

    So you have a C app which forks and the forked process runs an arpitrary system/backtick app? Does the logging happen in the forked process or the parent process? (I assume the forked process here).

    The last thing is, being unfamiliar with sysV streams, what sort of information is it passing back that you need to get?... Just the process name it wants to run or something more? Wouldn't the parent have to know that before forking?

    I may have misunderstood much of what you have said and if so I will revise this post as needed.


    dEvNuL
      The C app is a basically simple logging daemon, which listens on a pipe.

      The major application is a job management system (Perl), which monitors for events and maintains resource and dependency information. When the everything is in place for a job (file came in to process, another job finished, whatever) then a new job is spawned which runs commands to process the job.

      The main monitor logs to this pipe, and when children are forked off they send some initialization data down the pipe to identify themselves and also redirect their stderr stdout to this pipe for logging.

      Where sysV streams come in, apparently even though both the parent and children are writing to the same copy of the pipe connection that they got through the fork, somehow the C app is able to figure out which process each incoming line is coming from.

                      - Ant
                      - Some of my best work - (1 2 3)

Re: Porting a system 5 streams app to linux
by rg0now (Chaplain) on Apr 29, 2005 at 19:29 UTC
    What you describe here is a pretty strange sementics, at least for me, socialized on Linux. As far as I can understand you, you require that two or more processes write to the same pipe and the other side, by some miraculous way, can still distinguish between the senders of data. I do not know any facilities on Linux that can provide this to you (but I did not know about sysV streams either, before reading your post, so I might not be relevant here).

    However, for me it seems that the only cause you want to do that is to be able to use a C program further, just for the purpose of logging. I know that you might not like this recommendation, but why not get rid of the C program then, and just use some native Perl logging facility, like log4perl? This may save you serious headaches in the long run -- at least, for me it did...:-)

      Hehe... obviously I did not explain well... We want to get rid of the C program and turn it into Perl, I was just curious if there were other options that I was not thinking of to do the logging/IPC. Though I ran a mockup with INET tcp that ran about 7000 lines a second, so I think we are all set. I will look at log4perl, however. Thanks!

                      - Ant
                      - Some of my best work - (1 2 3)