Feature ITW logging tasks implementation

[Jiri Vanek]

 > Some general thoughts and comments below.
 >

Thank you both for them

 >> Hi all, before to much code is written. I would like to ask you to opinions about suggested approaches:
 >
 > How about we try and tackle one thing at a time? Does it make sense to
 > implement one of syslog or file logging first?

Because deeper and deeper I'm getting into them, they seems to me more and more connected

 >
 >>     - file logs are saved at
 >> {~/.config,$XDG_CONFIG_DIR}/icedtea-web/log without possibility to
 >> change this location... I think this is correct and I'm not going to
 >> change it (just going to higlight in ITW settings)
 >
 > But logs are not configuration. Would $XDG_DATA_DIR be more correct than
 > $XDG_CONFIG_DIR?

"$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.
If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used. "

 From specification, This do not seems me right the correct destination.

Anyway - I'm not against place them to anywhere if sombody insists.
My reasons to keep them where thay are now
  - less changes against 1.4
  - less places where itw is shred

 >
 >>     - java.stderr, java.stdout are no longer used
 >
 > What happens to java-side logs, then?
 >

What they were from orogin?

 >> logging to file(s) approaches:
 >
 > Is there any guarantee that two processes can write to one file without
 > stepping on each other's data? If not, then separate processes writing

I was trying to find this, and have not found. But made various experiments and it seems to be working really *perfectly*

 > to separate files is the only option we have (unless you want to use
 > some form of IPC for logging).

Ugh.. something I would like to avoid.
 >
 >>   - C and java sides are sharing the file and only one part is responsible for writing.
 >
 > What about when there is no plugin process (that is, there's just
 > javaws)? Does this mean that the java side has to handle the actual
 > writing?

Then jni stub have to be called => wrong, and right  now discarded solution.
The c--sendingDataTo->java---writingThem-> solution have also discarding disadavtage  - few logs can be lost before jvm is started (especially when plugi crash before jvm lunch)

But still can be interesting for "resurectin of console" (messages from C to java via pipes, and so console do not need to reload data from file)
 >
 >>    - this is probably just wrong idea, but there is no danger of conflict during writing into
 >>      - C part is sending the messages via pipe (new or current one), and java side is logging them
 >>        - advantage is usage of multithreaded logging on java side
 >>      - Java part is sending the messages via pipe (new or current one), and C side is logging them
 >>        - advantage can be in case of syslog(-ng) sytstem logger. The C api is much cleaner
 >>
 >>
 >
 > For the "combination" option, does this mean that the combined logfile will just contain the same information as in the other two separate logfiles, but with the log messages interleaved? This sounds good on one hand because it means some issues will be very easy to trace as data flows from one side to the other, but on the other hand it seems like this also leads to the logfiles' total size being 2x what it would be if we didn't have the combined file. What about keeping two separate files, so that debugging is easy and clean for issues that only really affect one side, but with timestamps on each message so if you are debugging an issue that needs both, you can still easily trace the data flow between them?
 > This would not be as easy to read through as the combined file however, and maybe the extra space taken up by the combined logfile is worth it. Anyway I guess I'm saying I like options 1 and 3 here.
 >

from what you have said I get inclined to option one - each side is writing to its own file. As one can easily get merged result from std. outputs.

 >> *System logging:*
 >> To be honest I got into dead end. Both me and pavel have tried
 >> several approaches, (abrt, syslog...) but none fit.
 >
 > I don't know anything about these systems. So I wont comment on this.

:(( Yah, appeared no one knows enough. I will lunch small voting + investigations in brno office

 >
 >> - I would like to log into syslog by default always and everything,
 >> and so if again somebody came and complain "it donot work", I will
 >> just tell him "look into well_knonw_location".
 >
 > "everything" including debug messages? Don't know if so much noise would
 > be helpful.

hmhmh... You are probably right.
 >
 >>     - multiline loggs must be allowed
 >
 > Not sure I understand this. What do you mean by multiline? Do you want,
 > say, an entire exception to be one log record?

Exactly. When full debug is on, then whole stack traces should be visible.

 >
 >>     - logs should be automatically rolled
 >
 > What do you mean by 'rolled' ?

Its common behavior of logging faclities, I just pointed it out, to not forgot it if we will go on some own or strange way.
rolled logs in my dictionary: eg log result is in some file, and after some time or reaching some size this file is moved to "archive" or renamed like log_date an new clean file is used...

 >
 >> As interesting approach of system logging may be just extension to file logging:
 >> Lets expect that directory /var/log/icedtea-web/ with 777
 >> permissions on icedtea-web exists (owened by root). Then We can have
 >> 700 permissions (owned y $USER)  directory $USER here, and log 600
 >> permissions files (owned y $USER) here in same way as we will do for

There can be security issue, that icedtea-web/$USER can be kidnapped, Especially linking can be hard to discover from java without NIO.

 >> "file logging". Stil the idea of ~.../log/ files should be kept. In
 >> this case I'm afraid of performance impact :(
 >
 > This would put 'user' logs in a funny place and without any benefit to

Maybe, but what is the place you are looking into when some app starts to fail? I'm firstly checking /var/log/{,messages,?}. And after that I'm searching app's specific logging facilities.
 > root (root will not be using icedtea-web, will it?). I don't see the
 > point of it. Perhaps I am missing something?

Use case I had in mind is shareed system, where itw have some global policies. In this system when user see itw do no work, he will contact admin. And he will check the logs.

 >
 >>
 >>
 >> - it is not widely , nor (haha) by default used/known
 >
 > I agree with all of the design decisions here but I don't know enough about system logging implementations to be able to help with choosing one or finding an alternative to syslog-ng. If it won't be in RHEL any time too soon, and if most other systems won't already have it installed, do we really want to make this system logger a new dependency for ITW? Even an optional one? Maybe in the future when it's more widespread. But again I'm not sure what to use in its place otherwise. It seems better to settle on something we can depend on being available on our end users' systems right now, even if that means it won't be as elegant as syslog-ng.
 >

I agree with you, Rather then taking dependency, which can not be everywhere, I would rather proceed with some custom solution.

 >> - Distors with packages can have syslog-ng as requirement, can start its daemon in post-install and can modify the syslog-ng properties file. (the config to reach above is not to simple). Not sure how to in non-packaging distros.
 >
 > In non-packaging distros, users would just need to set it up manually, I suppose. I don't think that's very ideal. We would then need to at least include some readme on how to configure this properly, and I'm sure most users would never bother with it at all anyway. Perhaps these users are a minority compared to those on packaging distros but I don't think we should make something as basic as logging be difficult to set up for them. I don't think it would be feasible for us to maintain a "setup-logging.sh" ourselves for this purpose either.


yah :(
 >
 >> *Logging settings"*
 >> Last item I would like to bring up before first line of code, is setting.
 >> Right now the settings are
 >>   - global
 >>    - debugging on/off  checkbook in itw-settings( or ICEDTEAPLUGIN_DEBUG or -verbose for javaws)
 >>    - headers on/of itw settings checkbox
 >> - which are affecting all  underlying outputs:
 >>    - streams
 >>    - file (only java implementation right now)
 >>    - system (nothing implemented)
 >>
 >> I'm thinking about individual settings (verbose and headers) of each stream.
 >> In ideal world I would like to see:
 >>    - streams - debug and headers off
 >>    - file  - debug and headers off, and headers off when debug on
 >>    - system (nothing implemented) -  debug and headers on
 >>
 >> With possibility to switch each separately to on/of for debug, and on/of for headers (so change for checkbox to commbobox in itw-settings, but I have no idea how to deal with -verbose and ICEDTEA_PLUGIN for this granular settings)
 >
 > Maybe those two options/switches should just add the minimal level of extra debug output. If that's still not enough then more verbosity can be enabled in settings. Or we can use multiple -verbose switches (and maybe add new short -v flag alias) to increase the amount of verbosity? One -v for some extra debug output, -vvv for maximum verbosity, something like that. I like the idea of having more granular control over what gets logged though.
 >
 >>
 >> Anyway. I'm not sure if this is worthy of effort (especially when I
 >> know that C headers generation are quite time consuming)
 >
 > I would encourage you to approach this from a user's (and root's) point
 > of view. Please think about what settings make sense and are useful.
 > I don't think it's a good idea to get very combination of everything
 > working. Rather, good default to make life simple for users (and
 > system admin) would be nice.
 >
 > For example, I don't think debugging stuff to syslog will be useful at
 > all. And syslog implementations should be able to add timestamps
 > automatically.
 >

This is something I was not able decide till now for  100%. I will experiment with it more.




 From above, and few more hints I'm inclining to following:
  -  the file-log will log to two files - one for plugin, one javaside,
  -  instead of remote logger, another "to file", but merged (one file for both java and c) which will log to /var/log/itw/user, and will be rolled.. /var/log should be probably configured via configure
  -  I would like to log into java console via pipes, few messgaes generated  before jvm lunch, can be written ..well somewhere .. to some file and loaded prior.:)
  -  we will stay with global headers/debug on/off, be defult off for all ways.