I have moved to a vagrant environment for developing a CakePhp site.
When viewing the new site there is a permission error with the log files.
Several log files are not writeable, with the following being an example output:
Warning (2): file_put_contents(/var/www/html/logs/error.log): failed to open stream: Permission denied [CORE/src/Log/Engine/FileLog.php, line 133]
I have been using puPHPet to generate vagrant configs.
My config file (config.yaml) includes the following:
mount_options:
dir_mode: '0777'
file_mode: '0777'
When I SSH into the box and run ls -al i see the following:
drwxrwxr-x 1 vagrant vagrant 0 May 16 16:21 logs/
and:
-rwxrwxr-- 1 vagrant vagrant 12152 May 16 16:53 cli-debug.log*
-rwxrwxr-- 1 vagrant vagrant 2763 May 16 16:53 cli-error.log*
-rwxrwxr-- 1 vagrant vagrant 0 May 16 14:12 empty*
-rwxrwxr-- 1 vagrant vagrant 0 May 16 14:12 error.log*
While they are owned by vagrant, they seem to have 777 permissions and thus should be writeable by any user.
How can I resolve this problem?
Thanks in advance.
Vagrant sets it's permissions a little confusingly. Following feedback I've updated these permissions.
This now works as expected.
Thanks to Salines and Greg Schmidt.
Related
I started having this issue today on our production sql server. I have tried a variety of different fixes proposed online. We are using MSSQL server 2017 (14.0.3257.3-13). I'm out of ideas on what could be causing the server to crash. Below is the recent crash log.
This program has encountered a fatal error and cannot continue running at Sat Feb 1 14:21:21 2020
The following diagnostic information is available:
Reason: 0x00000007
Status: 0xc000014c
Message: Corruption detected in persistent registry: \SystemRoot\security.hiv.
Stack Trace:
000000006b137250
000000006b1345bf
000000006b1347a3
000000006b1337d3
000000006b1326f2
000000006b175c31
Process: 8815 - sqlservr
Thread: 8819 (application thread 0x4)
Instance Id: e5a2f812-0426-4d92-b9b2-1db1e60d957c
Crash Id: 60073e70-4042-4275-9fcd-a05ae84d26f5
Build stamp: 9726a6583fe7826f57b03fd1c7adf12bebe7692cb64630fccb0541c06820af4d
Distribution: Ubuntu 16.04.6 LTS
Processors: 9
Total Memory: 8589934592 bytes
Timestamp: Sat Feb 1 14:21:21 2020
Last errno: 2
Last errno text: No such file or directory
Thank you for the ideas, Toret.
I have faced the same issue, but I solved it just by deleting the security.hiv file.
rm /var/opt/mssql/.system/system/security.hiv
After that the mssql-server service started normaly.
After working through multiple proposed solutions online nothing worked. Some of the things I tried:
Upgrading mssql-server to latest version.
Repairing missing files or dependencies.
Changing access permissions to the directory.
Elevating access permissions for the mssql user.
Changing user access to root for the .hiv files located in the mssql .system/system folder
The only way to for me to get it to work was to:
Delete all the folders manually from /var/opt/mssql/ except for the
data folder.
Re-link python from 3.5 to 2.7
Then I downgraded the mssql-server version to Microsoft SQL Server 2017 14.0.3192.2.
Run the sudo /opt/mssql/bin/mssql-conf setup
**Python Re-link**
sudo rm /user/bin/python
sudo ln -s /user/bin/python[version] /user/bin/python
After that everything worked again.
I get this error while executing
react-native run-android
I have tried copying tools.jar file to JRE installation location, reinstalled JDK and JRE, checked environment variables for path. Nothing worked.
It returned with the below exception
info Starting JS server...
info Building and installing the app on the device (cd android && gradlew.bat app:installDebug)...
Starting a Gradle Daemon, 1 stopped Daemon could not be reused, use --status for details
> Task :app:compileDebugJavaWithJavac FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:compileDebugJavaWithJavac'.
> Could not find tools.jar. Please check that C:\Program Files (x86)\Java\jre1.8.0_211 contains a valid JDK installation
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
For MacOS, here are the steps:
Get Current java version ( recommended 1.8 ):
$ java -version
java version "1.8.0_271"
Java(TM) SE Runtime Environment (build 1.8.0_271-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
CD to your Java home path
$ cd /Library/Java/JavaVirtualMachines
$ ls
total 0
drwxr-xr-x 3 root wheel 96B 24 Out 09:24 adoptopenjdk-15-openj9.jre
drwxr-xr-x 3 root wheel 96B 30 Dez 20:18 jdk1.8.0_271.jdk
CD to the current java home shown at step 1 (" java 1.8.0_271" ):
$ cd jdk1.8.0_271.jdk/Contents/Home
Note: if you can't find 1.8.0_271.jdk after listing the files in the folder, you might find another jdk file like this adoptopenjdk-8.jdk use it.
Copy the current path to clipboard:
$ pwd | pbcopy
Finally, open the gradle.properties file (here I'm using VSCode) and set the org.gradle.java.home variable:
org.gradle.java.home=<path_to_current_java_home>
Her is an working example:
Add this to gradle.properties:
org.gradle.java.home=C:\\Program Files\\Java\\jdk1.8.0_91
Don’t forget to use double back slashes. For example:
org.gradle.java.home=C:\\Program Files\\Java\\jdk1.8.0_144\
This is because valid jdk path could not be detected. Go to your project, open android folder > gradle.properties file > add below line:
org.gradle.java.home=/Applications/Android Studio.app/Contents/jre/jdk/Contents/Home
and you are good to go ;)
For me in MacOS the path to put in gradle.properties was:
org.gradle.java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home
I followed the instructions on https://ctors.net/2015/07/14/solr5_java8_debian8.
As the root
First I installed Java 8:
mkdir -p /opt/java
wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/8u45-b14/jdk-8u45-linux-x64.tar.gz"
tar xvf jdk-8u45-linux-x64.tar.gz -C /opt/java
update-alternatives --install /usr/bin/java java /opt/java/jdk1.8.0_45/bin/java 1
update-alternatives --set java /opt/java/jdk1.8.0_45/bin/java
Then I installed Solr:
wget http://apache.belnet.be/lucene/solr/5.2.1/solr-5.2.1.tgz
tar xvf solr-5.2.1.tgz
./solr-5.2.1/bin/install_solr_service.sh solr-5.2.1.tgz
But the installation ends up with the following error message:
solr.service - LSB: Controls Apache Solr as a Service
Loaded: loaded (/etc/init.d/solr)
Active: failed (Result: exit-code) since Wed 2015-11-18 02:29:36 TMT; 5s ago
Process: 1679 ExecStart=/etc/init.d/solr start (code=exited, status=1/FAILURE)
Nov 18 02:29:36 solrhost su[1681]: Successful su for solr by root
Nov 18 02:29:36 solrhost su[1681]: + ??? root:solr
Nov 18 02:29:36 solrhost su[1681]: pam_unix(su:session): session opened for user solr by (uid=0)
Nov 1`enter code here`8 02:29:36 solruser solr[1679]: This script requires extracting a WAR file with either the jar or unzip utility, please install these utilities or con...assistance.
Nov 18 02:29:36 solrhost su[1681]: pam_unix(su:session): session closed for user solr
Nov 18 02:29:36 solrhost systemd[1]: solr.service: control process exited, code=exited status=1
Nov 18 02:29:36 solrhost systemd[1]: Failed to start LSB: Controls Apache Solr as a Service.
Nov 18 02:29:36 solrhost systemd[1]: Unit solr.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.
Service solr installed.
Does anyone have any idea what is going on?
solr needs unzip to work. Install unzip if it isn't available on the system.
apt-get install unzip
It should fix the problem.
I got my colleague to have a look at the issue. He found two causes of error:
1) Insufficient memory (my box had 512 MB RAM memory). Additional memory resolved the issue.
2) Wrong jdk package, that is, wrong architecture choice. For different JDK packages look here: http://www.oracle.com/technetwork/java/javase/downloads/java-se-6u24-download-338091.html.
Hope someday this will save someone else's time and nerves.
As for Debian and Solr developers, it would be great if you could come up with simple receipt about how to install Solr 5 under Debian 8. For example, https://www.digitalocean.com/community/tutorials/how-to-install-solr-5-2-1-on-ubuntu-14-04.
I need to create a simple script (Windows .bat) that will provision or up a box.
Not much experience with .bat files, so this is what I have so far:
Edited thanks to Greg Hewgill
cd C:\vagrant-box\
call vagrant-up.bat
if errorlevel 1 call vagrant-provision.bat
The .bat files called in the script just contain one line: vagrant up and vagrant reload, respectively.
When the vagrant box is down, then vagrant up runs successfully. When up, I encounter an error with vagrant up (which I expect) but the whole batch file dies there. ErrorLevel doesn't appear to do anything.
Here is the error if it makes a difference
Bringing machine 'default' up with 'virtualbox' provider...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["list", "hostonlyifs"]
Stderr: VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: Code CO_E_SERVER_EXEC_FAILURE (0x80080005) - Server execution failed (extend)
VBoxManage.exe: error: Most likely, the VirtualBox COM server is not running or failed to start.
I want to emphasize I don't care about the error per se. It works when the box is not running, so it's fine. I just want to capture or ignore it, and move to the next command.
vagrant up exits with code 0 even if the machine is already running.
But you don't have to bother with exit codes, you can just run:
vagrant provision && vagrant up
And you should cover both cases. If the guest is not running, vagrant provision will gracefully fail and vagrant up will succeed, and vice versa.
Please post your vagrant-up.bat.
Also, try either this:
vagrant up --debug
and/or
VAGRANT_LOG=debug vagrant <action>
To get more detais about the COM/VBox issue.
Everything worked on 10.5, but now my PackageMaker installation project is broken. I've been fighting a problem for a few days now, and either
Snow Leopard (OS X 10.6.1) has broken PackageMaker installations
I am lacking a very, very basic tidbit of knowledge
To narrow down the problem, I've gotten to this point:
Create a new PackageMaker installation
Have it install a jpeg image into my home directoy
Define a preinstall script that does nothing
#!/bin.sh
exit 0
Run the above...and watch it fail with the below error message like clock work
Sep 14 15:09:45 manoa installd[5620]: PackageKit: ----- Begin install -----
Sep 14 15:09:45 manoa installd[5620]: PackageKit: request=PKInstallRequest <1 packages, destination=/>
Sep 14 15:09:45 manoa installd[5620]: PackageKit: packages=(\n "PKLeopardPackage <file://localhost/Users/stu/Desktop/asdf.pkg>"\n)
Sep 14 15:09:46 manoa installd[5620]: PackageKit: Extracting /Users/stu/Desktop/asdf.pkg (destination=/var/folders/Hb/HbXJFyEpFaupt5QyLN-pTk+++TI/-Tmp-/PKInstallSandbox-tmp/Root/~, uid=501)
Sep 14 15:09:46 manoa installd[5620]: PackageKit: Executing script "./preinstall" in /private/tmp/PKInstallSandbox.cmlS2H/Scripts/test.test.5year_header.pkg.PFrHNB
Sep 14 15:09:46 manoa installd[5620]: PackageKit: *** launch path not accessible
Sep 14 15:09:46 manoa installd[5620]: PackageKit: Install Failed: PKG: pre-install scripts for "test.test.5year_header.pkg"\nError Domain=PKInstallErrorDomain Code=112 UserInfo=0x100149430 "An error occurred while running scripts from the package “asdf”." {\n NSFilePath = "./preinstall";\n NSLocalizedDescription = "An error occurred while running scripts from the package \U201casdf\U201d.";\n NSURL = "file://localhost/Users/stu/Desktop/asdf.pkg";\n PKInstallPackageIdentifier = "test.test.5year_header.pkg";\n}
Sep 14 15:09:46 manoa Installer[5614]: install:didFailWithError:Error Domain=PKInstallErrorDomain Code=112 UserInfo=0x1195917c0 "An error occurred while running scripts from the package “asdf”."
Sep 14 15:09:46 manoa Installer[5614]: Install failed: The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.
Sep 14 15:09:47 manoa Installer[5614]: IFDInstallController 144040 state = 7
Sep 14 15:09:47 manoa Installer[5614]: Displaying 'Install Failed' UI.
Sep 14 15:09:47 manoa Installer[5614]: 'Install Failed' UI displayed message:'The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.'.
There is no file in /private/tmp/PKInstallSandbox.cmlS2H/Scripts/test.test.5year_header.pkg.PFrHNB/, which makes me think the problem is with PackageMaker, and not me. But I'm new to the world of OS X software installation, so doubts remain.
So, the question: Is PackageMaker with a preinstall script broken on OS X 10.6? Or is there some requirement regarding preinstall scripts that I do not understand?
I had the same problem and setting the executable permissions for the scripts solved it for me!
pkgutil --expand my.pkg my
chmod +x my/inner.pkg/Scripts/preinstall
pkgutil --flatten my my-fixed.pkg
Found this solution in this thread at golang-nuts groups
"launch path not accessible" may very well have to do with which software is zipping and/or unzipping the PKG.
So, I was having the problem that my postflight script was not running and was causing my PKG to fail. Looking at the installer log (to see this run the PKG in question, then menu item 'Window > Installer Log' and select 'Show All Logs' from drop down) I saw the dreaded 'launch path not accessible' when it was trying to run script (renamed by PackageMaker to 'postflight').
The problem was only showing up on my customer's systems. It was a real stumper as both of my Mac test machines had no problem running the PKG and their environments appeared to be the same as the customer's machines.
Then in an obscure post on a Symantec website I saw that someone discovered that this problem has something to do with how the PKG is being zipped and/or unzipped.
Sure enough. My customer was downloading the PKG from DropBox and the way that DropBox was zipping it corrupted something inside the PKG.
The solution was for me to ZIP the PKG on my system before uploading to DropBox and then everything worked swimmingly.
I had the same problem. Check the first line of your script. In my case the ! was missing
from the #!/bin/sh