I am trying to isolate a problem in a backend logic using log file. I have made a custom log file for the purpose because default log file has too much content to filter through. The module is already live so I have to read the log file from the server to debug the problem. I noticed that while performing commit, the log files I created was in gitignore. So I wanted to know how it works. Are log files generally placed in gitignore? And do servers make their own log files?
Yes, the server will create its own log file. Version control should not work with them since the information they contain will be relative to the environment in which they are contained (your server in this case). Therefore, by default, in the storage/logs directory you will find a .gitignore file with the content:
*
! .gitignore
which will cause none of the files contained in it to be managed by Git.
If your new log file is in this directory, it will not be processed by Git either.
Related
I'm following the Scripts with Support Files answer from here https://stackoverflow.com/a/46479538/4771016 which works great but running into a problem during the update of my script.
If not found, my script creates an .env file for the users to pass some variables in the same directory as the .sh file lives: /home/linuxbrew/.linuxbrew/Cellar/myscript/1.0.2/libexec/.env the problem is that upon releasing a new version, the .env file won't be in the new directory i.e. /home/linuxbrew/.linuxbrew/Cellar/myscript/1.0.3/libexec/ and thus will be recreated losing the modifications.
Any ideas for keeping that .env file during updates or an acceptable design pattern for my use case? I was thinking about keeping the .env file outside that directory somewhere, but I don't know the Homebrew directory structure well enough to store it in the right place.
I am using git in cli to change the current branch:
git checkout dev
and it produces:
fatal: cannot create directory at 'app/src/androidTest/java?com': Illegal byte sequence
As answered in this question and this one, I tried:
LC_ALL=C git checkout dev
or
LC_CTYPE=C git checkout dev
but I am getting the same error as shown above.
Running:
git status
shows that some of the files were changed by the checkout, but I am still on the master branch.
How can I remove the file causing the problems or how can I checkout the branch without getting this error?
The locale only affects how things are displayed. If the file name contains a character which isn't allowed by the file system, no amount of locale tweaking can fix that.
I can't think of a way to force a file system to let you create a file which then cannot be used, or a good reason to want to be able to do that.
Probably as a workaround, create a virtualized host with a bare-bones Linux system formatted to permit old-style 8-bit file names (Latin-1 or CP1252 if you can live with the unsavory Windows flavor of that), check out the file there, rename and commit the rename back to git. You still won't be able to check out versions of the source tree from before the rename.
I have found a few files in various github projects that are not compatible with one or another operating system. Files with a ".nul" or ".con" extension are a real pain on windows, for example. It isn't a problem exclusive to git. For example Subversion will abort nastily if it can't restore a file for local naming reasons.
In some cases the file may have been uploaded in error. If that is the case for your own projects it should be possible to use the git tools to list the archive and perform a delete of the file from the archive without actually instancing the file locally.
In other cases perhaps that particular file is not significant, and perhaps can be ignored. Perhaps a test will fail if it is missing?
One trick I have used is to stop the whole folder containing that file from being synced by manually creating the directory path, but for the last element, create an empty file instead of a folder. Of course, now the whole test suite will fail.
When the version control tries to do the checkout, it will simply fail to restore the folder, rather than giving a fatal error.
Of course, that only works if the folder is non-critical, e.g. some test files.
The alternative is to piecemeal check-out all but the problem file, but that can be a tedious sequence of checkouts. But you can use this attack to restore the rest of the folder that you omitted using the above technique. Alternatively, locally drag the files from the zip download if they are non-critical.
I am trying to update a module to a newer version. In the past I have manually uploaded each file carefully into the new directory and overwritten older files using FTP. However I wanted to use SSH to try and do this more easily and without any file permission problems.
I have:
Uploaded the .tgz file to the root folder (/http) on the server
Logged into the server via SSH
Changed the directory to the correct directory
Run the following command: tar -zxvf fishpig_splash.tgz
In the command line I was then given a list of all the files that had been extracted. However if I use FTP to go to any of these files I can see that they are still the older version and have not been overwritten.
I was expecting that the files would extract into the correct directories and overwrite any that already existed. I have tested the extraction by creating a temporary directory and extracting into that and everything worked fine.
Is there another part to this script I need to use to overwrite the files?
Thanks
Glynn
Sorry this was just me being stupid! When extracting the tar file there was a subfolder within it for the extension, I completely missed it. I just went down a level in the file and zipped up the contents only then extracted them at the root and everything worked fine. Thanks for the help though!
My .csv recreates on every release, and, as I understand, to keep its data unchanged between deploys I need to put it in /shared directory and simlink to it from my deploy.rb.
Is this the right route? (I have this question because I don't seem to find much info on how to do this with respect to, eg, databases, for some reason. /shared directory is mostly used for .conf files and paperclip-like directories).
When using capistrano, your application code will be "uploaded" to some directory on the server. Capistrano uses this structure:
/path_to_folder:
current - symlink to the directory with the current release
releases - contains all kept releases
shared - files that should persist between releases
So to your question - copy the .csv file somewhere into "shared" directory and then in the config/deploy.rb add this:
namespace :deploy do
task :create_symlinks do
run "ln -s #{shared_path}/something.csv #{latest_release}/db/something.csv"
end
end
after 'deploy:update_code', 'deploy:create_symlinks'
Replace "something" with the file name that you copied. You can also put the csv file into some directory under "shared" if you want to, I'd use "db" in this case. If you do so, don't forget to update path in the symlink.
Under config.php I have:
$config['log_threshold'] = 4;
$config['log_path'] = '/home/myaccount/logFilesFolder';
In index.php I have:
error_reporting(E_ALL);
The only way I can seem to get anything to log is if I chmod that directory to rwx (777), which doesn't seem right to me. That and it doesn't see to be logging all the errors.
In my local/dev environment it seems to be working but on my production server nothing is being logged. I can't seem to figure out why.
The log filename in the configuration settings needs a trailing "/" above making sure the webserver process has writeable access to the directory.
Change the logs owner and group to what owner/group your live web server is running, give it write perms and it should work. I take it that in your local/dev server your CI folder is owned by you that is why you need to chmod it to 777 to make it work.
The directory where you want the log files to be saved needs to be writable.
I have tried a lot of solutions and finally what worked for me was this:
Open system/libraries/Log.php
and change the following lines;
set the value of: $this->log_path to a writable directory, preferably home directory so that there are no permission issues. If you want to change the filename also, search for the variable $filepath and change the name.
Example:
$this->log_path = '/log';
touch /log/
restart the webserver.
The logs will start coming.
I have tried a lot of other options, none worked, this is not neat approach but at least I can see my logs now.
I had the same problem with my Codeigniter 4 project. The log was created successfully in my local window machine but was not creating on the remote Linux machine. I was using a custom path to generate log files under the 'app' folder. So what I did is to change the settings in my config/Logger.php file back to
'path' => WRITEPATH.'logs/',
and it created the log files under writeable/logs folder.