Node.js logging gets an issue when log files are rolling by OS. - node.js

I have Node.js application which is running under Linux system and uses log4js logging library. Log files are daily rolled by Linux rolling system. The question is the following: somebody know how force the log4js to recreate and use original log file when it's renamed somehow?
Note, Log4js continue writes log into renamed file (seems, stream descriptor is kept).
Please note also that I don't want to use log4js DaylyRollingFileAppender because my log folder contains log files generated by various languages (Java, Python, JavaScript, Bash...).

I assume that you use logrotate.
You can try using 'reload' directive in logrotate config file. (see for details: http://www.linuxcommand.org/man_pages/logrotate8.html)
It seems like that log3js can handle SIGHUP. (Issue: https://github.com/nomiddlename/log4js-node/issues/343, Pull request: https://github.com/nomiddlename/log4js-node/pull/403)
Secondary solution is configure it to use 'copytruncate' directive, but it has trade-offs:
https://serverfault.com/questions/688658/rsyslog-with-logrotate-reload-rsyslog-vs-copytruncate

Related

Where to save CLI application log file that will work cross-platform?

I have an application that saves error logs into the same directory where the script was run. This is bad because it creates error.log files in random places. So I want to save the file into /var/log on GNU/Linux and I would like to have the same for Windows and macOS (and probably any other OS where NodeJS runs).
Is there a cross-platform way to get a log directory? So I can write logs there?
Also how to work with that directory if it's owned by root. Or is there a better place to save NodeJS application logs?
The only directory cross-platform NodeJS directory is /tmp using:
const log_filename = path.join(os.tmpdir(), 'lips.error.log');
What is the best place to save logs where users can look them up? Same directory and /tmp directory are not good options in my option. What are the other options to save logs files?
What is the usual place where log files should be saved cross-platform in any CLI application?
That's part of the fun -- there is no single directory to store logs, so you'll need to handle each supported OS separately.
Linux has options, but it would be good to go for the XDG specification way, as it's a reasonable standard that won't fill up system logs, and it will make it simple to isolate the applications logs.
macOS can use the ~/Library/logs folder.
Windows can use the AppData folder, usually AppData/Local.

How should I access the file system of the VSCode's user?

So I am making a VSCode extension. It should read and modify files of user's file system. Should I do it with node's fs or should I use some VSCode's interface/API for this?
If the latter is correct then what is the API namespace I need (workspace or something)?
If the former is okay, how can I really use fs? What if the user does not have node.js installed? Or is it always installed with VSCode?
It depends.
In general use vscode's TextDocument api for:
Reading text files from the workspace. This api ensures that you always read the current state of the file (even if it has not been saved to disk yet).
Modifying text file content in the workspace. You can also use save to write a modified file back to disk.
Reading resources from file system providers
Use fs for:
Reading and writing files that are outside of the workspace.
Reading and writing files that should not be tracked by VS Code. Opening a TextDocument can cause VS Code and its extension to try processing the file.
Reading and writing binary files.
This api proposal would also be of interest for you. It would enable more low level file reading/writing directly using VS Code.
(Also, you can always safely use node since VS Code includes a copy for extensions to use)

Log4j Shared Log file Rolling file appender issue

I was asked to assist in debugging a peculiar issue, related to log4J.
They are facing issues with the rolling file appender. There are multiple EJB applications writing to the same log file. Each application has its own log4j.properties.
Issue: The latest log files are being written to a file trace.log.x instead of trace.log. Is there any setting which needs to be added? I could not really find an anomaly. Below are the settings.
log4j.rootLogger=INFO, A3
log4j.appender.A3=org.apache.log4j.RollingFileAppender
log4j.appender.A3=org.apache.log4j.RollingFileAppender
log4j.appender.A3.File=$variable/trace.log
log4j.appender.A3.MaxFileSize=10MB
log4j.appender.A3.MaxBackupIndex=5
I was wondering if I need to set the log4j at the server level instead of the app level. I don't like the idea though. I am not in favour of log file being shared. There is no log file corruption, but looks like the wrong file is getting updated

log4j:WARN Please initialize the log4j system properly; still Log file created,but not in UNIX

I'm developing web application which has commons-logging.jar and for logging log4j.jar.
I got the following message when server start up.
log4j:WARN No appenders could be found for logger (org.apache.struts.util.PropertyMessageResources).
log4j:WARN Please initialize the log4j system properly.
But still log file is created and the format also same as specified in the log4j.properties.
The application log file is creating in Windows environment, But not in Unix environment.
Why it is not creating log file in UNIX ? Folder has write permissions..
Any idea?
Laxman Chowdary
The message you get on server startup is just a warning, your log file should be created inspite of it (you can find an explanation for the message in this post).
Why the file is created in Windows but it doesn't get created in Unix could be caused by lots of reasons: permissions for the user under which your application is running are first, maybe the configured path is still a Windows path (e.g. containing C:\ maybe), perhaps you meant to use an absolute path and forgot to prepend the / to it...
it's hard to say without seeing your configuration. Check these first and maybe update the question with the configs you are using.
Sometimes what can happen is that you use a relative path for the file and the file gets created relative to some folder in Windows and you expect it to be the same in Unix. But the "current folder" might be another in Unix. Maybe the file gets created but it's located in another place? Try searching for it on disk...

How can I retain existing log file permissions with Log4J DailyRollingFileAppender

I have a jar file which internally use log file to write messages. Using this jar I have developed a Perl module. The usage of this module is across out firm. So I have given 666 permissions on all the log files so that everyone can use the module. The issue is the jar file internally uses log4j and the appender is DailyRollingFileAppender which is resetting the permissions on the log files to 664 after rolling and certain people are not able to use the module.
Is there a way to mention to log4j to retain the existing permissions of the log file ? If not, can anyone suggest alternative ?
This is the responsibility of the operating system. When Log4j rolls a log, the OS will create that new file according to its own rules.
You should be able to reproduce this manually, by opening a shell in the log directory and running touch testfile - the file testfile should exhibit the same permissions as new log4j files.
You need to look at the file permissions on the directory, those that are inherited by new files in that directory. You may also need to tinker with the user's umask setting.
If you can reproduce the problem without using log4j or java, then it becomes easier to solve, but would be best asked on superuser.com.

Resources