UNIX for Dummies Questions & Answers

Would you prefer unexplained crashes?

There's ways to reduce redundancy of course. It's useful that any failed system call, and quite a lot of things in stdio, set errno on error, so the same error routine can be used for many things:

Code:

// Opens a file, reads 'size' bytes from it, returns the data in new memory
void *read_data(const char *filename, int size)
{
        FILE *fp=fopen(filename, "r");
        void *mem=NULL;

        if(fp == NULL)
                goto PREPARE_ERROR;
        if((mem=malloc(size)) == NULL)
                goto PREPARE_ERROR;
        if(fread(mem, 1, size, fp) != size)
                goto PREPARE_ERROR;

        fclose(fp);
        return(mem);

PREPARE_ERROR:
        // fread, malloc, and fopen all set errno on error.
        perror("error in prepare_something:");

        if(mem) free(mem);
        if(fp)      fclose(fp);

        return(NULL);
}

...which just amounts to an extra jump-if instruction or so between function calls. The lion's share of work is done by functions or non-error code. And the benefit of error messages if your program actually does misbehave is enormous.

perror goes to standard error incidentally, so if you redirect FD #2 into a logfile, perror goes there.

I would like to thank you again also for the help with emulation.

What is the technical term for writing the code that sources the log files like klogd and syslogd? I run my own code that oversees how my programs intentions panned out, then I use a logger command correct?

What system resources aide in determining if an error has occurred? Proc, Trace , OOP events and what else?


I expect to find a lot of intentional documents on this subject but it looks like everyone must just wing it.

You mean, writes the log files?

How about "error logging"? Depends what you're trying to do. Generally none of the above. Unless something goes seriously wrong like a segfault, generally only your program knows if anything's going wrong.

An 'OOP event' in particular isn't a real thing. It's a programming method/buzzword. Object-oriented programs still deal with the same things.

In the end, checking for errors means checking if any data you receive makes sense, and checking if system calls you make succeed or not. It sounds like you're reading papers describing what should be done but not how.

What, exactly, are you trying to do here? It sounds almost like you've been handed a list of substanceless buzzwords from on high and been told to obey them.

If I could find a document on this subject I would read it but all I can do is try to poke at it and search terms on the Internet. A web search on "error logging" yields next to nothing btw.

If a search is done for "logging" all the information is from the "event code" the programmer writes (to) the separate logging application. Nothing further up the steam can be found in a structured document.

I have no doubt that a applications execution must be verified so it can keep on executing but I Can Not find any structured, predetermined approach to study the customary tools and methods used. I assume that there has to be a lot of O.S tools available or C library commands. The syslogd might be something to research because it is just really an application with oversight. I can't fathom that there is not entire books and coarses written on this subject so just brainstorming up methods to do this seems like reinventing the wheel. Augh! Experienced programmers Must have a procedure that they follow instead of doing it on the fly.

A book title of " How to write Code that produces the data held in Log files" would be the ticket.

You're really overthinking this. It's like looking for a specification designed to print the letter 'A', and because there's no specifications specifically about printing the letter 'A', deciding that printing the letter 'A' is something very mysterious, complicated, and badly documented.

You can either write error messages to stderr, write them to a file, or use the system logger. Shell utilities usually use stderr. System daemons usually use files or the system logger. What an 'error' is, and what deserves logging, is up to you. syslog in particular lets you tell it how important the message is when you make it.

What's more useful to know is how other things return errors. See man errno, the global variable many things set on error. There's also a set of functions to use with it. Also see man 3 syslog for the "standard" way errors are recorded on a UNIX system -- it's not just a library call, there's log-related parts of the kernel it talks to.