Subject: Re: [Netatalk-devel] Logger

From: Carsten Neumann <[email-masked]>
Date: Sat, 24 Nov 2001 01:00:12 +0100

On Fri, 23 Nov 2001, Glenn Trewitt wrote:
> How about argv[0] in main()?  You might want to trim the string down to get rid of the path, but that's the Right Thing to do.
>     - Glenn

I think argv isn't available at that point.

If you have a /proc file system you can readlink(2) /proc/self/exe.

HTH
Kind regards

	Carsten

---

From: Joe Clarke <[email-masked]>
Date: 24 Nov 2001 06:35:46 +0500

> If you have a /proc file system you can readlink(2) /proc/self/exe.

argv is available to the parent afpd.  You can't use /proc since that is
not a portable solution.  This code in the main() function of afpd is
probably the best alternative:

#include <libgen.h>
...
char *cmd = basename(argv[0]);
LogSetup(cmd, ...);

Joe

> 
> HTH
> Kind regards
> 
> 	Carsten
> 
> _______________________________________________
> Netatalk-devel mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>

---

From: Carsten Neumann <[email-masked]>
Date: Sat, 24 Nov 2001 05:13:32 +0100

On Sat, 24 Nov 2001, Joe Clarke wrote:
> cchar *cmd = basename(argv[0]);
> LogSetup(cmd, ...);
> 
> Joe

You assume that the function call will be somewhere in the program where argv is available.

But I wrote that I think that at the point where the requested function is performed argv is not
available.

I also think the questioner is well aware of the fact, that he could simply use argv[0] to get
the program name - from main or some function to which argv is passed.

So the requested function must be called from somewhere else - e.g. a library which has no access
to argv.

I'm sorry that my suggestion will not work on all platforms, but it should work at least on linux
with /proc filesystem - which is the default for (almost?) all linuxes, for the rest there must be
found some other solution.

BTW: what is a `cchar'? Your personal typedef of `const char'?

Kind regards

	Carsten

---

From: Joe Clarke <[email-masked]>
Date: 24 Nov 2001 10:18:28 +0500

> You assume that the function call will be somewhere in the program where argv is available.

Yes, it will.  For afpd, it will be in the main function of afpd. 
Logging will be setup there, then used by all the children.

> But I wrote that I think that at the point where the requested function is performed argv is not

If argv isn't available, you have to use another method.  The call
getprogname() or something like it should be used.  However, netatalk is
divided into executable processes, so argv will always be an option.

> So the requested function must be called from somewhere else - e.g. a library which has no access

Why?  The library will be initialized from a program that contains a
main() function.  Give me an example of how a library magically runs
itself.  Take a look at the code.  openlog() is called from
afp_options.c.  openlog() is a library call.  And guess what?  It's
called with an argument of char *p.  What is p, you ask?  It's basically
basename(argv[0]).  Now why can't Simon's logging code do that as well?

> found some other solution.

You should _never_ opt for a programming method that is non-portable. 
Isolating *BSD, Solaris, and Tru64 is not a way to make friends.  The
argv[0] method is fine.  Else you could statically compile in the name
as afpd (or whatever) if you absolutely had to.

> BTW: what is a `cchar'? Your personal typedef of `const char'?

A mistype.  It should be char.

Joe

---

From: Carsten Neumann <[email-masked]>
Date: Sat, 24 Nov 2001 06:28:09 +0100

> getprogname() or something like it should be used.  However, netatalk is

Sorry, can't find getprogname() in my headers/man-pages.

> basename(argv[0]).  Now why can't Simon's logging code do that as well?

So now I don't understand the reason for this question at all.

To know that the program's path is in argv[0] is BASE KNOWLEDGE.
If the programmer doesn't know this he/she must be a C-beginner.
This is not a C-learning mailing list!

I wouldn't trust logging code from such a person.

> as afpd (or whatever) if you absolutely had to.

It was NEVER my intention to isolate other platforms.
This was just a suggestion from the best knowledge of one platform I know!
If it isn't portable is has to use some #ifdef <PLATFORM>.

> A mistype.  It should be char.

K'pla

	Carsten

---

From: Simon Bazley <[email-masked]>
Date: Sat, 24 Nov 2001 13:57:35 +0000

Ok, OK, I've done it already *grins*

There is a SetProcessName function for those that want to use it and a function LoadProcessNameFromProc (spelt with 2 c's ie wrong for the time being, DOH) to do the linux thing.

I'm sure the non linuxs have a ps function and it must have a means for getting the processname.  Anyway, for the time being we can use SetProcessName (which is called by LoadProcessNameFromProc).

The real question is with all this going on today, can we put the logger in the main trunk?

The current setup has 3 important points.
1) The syslog bit, which is setup by default.  It will log everything to syslog as per usual.  It is configured by a call to SysLogSetup with a different loglevel or logtype.  I should probably change it to add the filename/line of the caller (which
currently only gets logged to a file).  This I believe does exactly the same as the current calls to syslog, with a bit of enhancement with the loglevel and logtype string being prepended to what would normally have been logged to syslog.  It also has a
limit in the logstring length of 512 charachters (whcih I think should be enough).
2) The file logger bit.  This logs to a file which currently defaults to a localfile, called debuglog..  Thats not really desirable, but as soon as someone calls LogSetup, they change that anyway.  The directory this new file will exist in is set to
'/var/log/netatalk/'.  Thats currently hard coded, but theres no reason why that cant be set by a configure option, or changed by giving a filename that overrides it (will a call to fopen with name '/var/log/netatalk//root/debuglog.log' ignore the
/var/log/netatalk bit?).  Either way if the LogSetup call sets the loglevel to log_severe then the whole section is pretty much turned off.  Using a LogLevel of -1 will turn it off completely.
3) An enchancement to the file logger bit.  If the file logger can't open the logfile its been given (ie the directory /var/log/netatalk doesn't exist) then it will log to stdout for the process.

There are a number of improvements that still need to be done, but at the very least it doesn't to anything less than a call to syslog (except the 512 char limit).  Hence I ask is it ready to leave its lonely home in 'tagged_to_work_on_logger' and go into
the main trunk?

Simon

---

From: Simon Bazley <[email-masked]>
Date: Sat, 24 Nov 2001 14:04:24 +0000

Oh, and another thing:

My coding style is to use capitalised descriptions on everything (LogSetup) and to use vaigly informative global variables (arrMyArray and numMyArray for the array and the number of items in it).  I also indent with
if
{
<- 2 spaces indenting
  if
  {
  }
  else
    another command
}

Is there a standard style used in the rest of netatalk that I've missed or is it just every man for himself, cause if there is another coding style I'll change the code I've done.  Its quite annoying reading through lots of code layed out in different
ways.

Simon

---

From: Joe Clarke <[email-masked]>
Date: 24 Nov 2001 21:51:01 +0500

> Is there a standard style used in the rest of netatalk that I've missed or is it just every man for himself, cause if there is another coding style I'll change the code I've done.  Its quite annoyi…

I recommend the use of astyle on all code.  Also, none of the functions
in netatalk are capitalized.  Instead '_' are used to separate function
name components (e.g. cnid_open, afp_getfilparams, etc.).

Joe

---

From: Joe Clarke <[email-masked]>
Date: 24 Nov 2001 21:53:46 +0500

> The real question is with all this going on today, can we put the logger in the main trunk?

No, the real question is why are you still focusing on a Linux-only
solution?  And why do you need a function to set the process name in
your logging code?  You should force the developer to use LogSetup (or
probably log_setup()) to initialize the logging environment.  From
there, the developer should pass the name of the current running
program.

> There are a number of improvements that still need to be done, but at the very least it doesn't to anything less than a call to syslog (except the 512 char limit).  Hence I ask is it ready to leave…

Sounds like it's still too early to move this code in main stream use.

Joe