I am trying to install supervisor on my Fedora 17, using this link as reference:
https://www.digitalocean.com/community/articles/how-to-install-and-manage-supervisor-on-ubuntu-and-debian-vps
It works fine except one trivial problem (I believe).
A simple configuration for our script, saved at /etc/supervisor/conf.d/long_script.conf, would look like so (...)
My problem is, that I have only files/directories:
/etc/supervisord/
/etc/supervisord.conf
I have tried to create conf.d directory under /etc/supervisord/. I have put my config file into /etc/supervisord/conf.d/ and /etc/supervisord/ and also /etc/sueprvisor/.
Despite my effort when issuing command:
supervisortctl reread
I receive:
No config updates to processes
Anyone has a clue what I might be doing wrong? Thanks in advance.
(I'm on Fedora 20) If you look at /etc/supervisord.conf at the bottom you see
[include]
files = supervisord.d/*.ini
So on Fedora your configuration files should end in .ini instead of .conf. I had this same problem and running supervisorctl reread after this detects stuff
There is no need to create a folder specifically for your configuration file, you can specify its path with the -c /path/to/your/file or --configuration=/path/to/your/file option.
Source: http://supervisord.org/running.html
Related
I am not able to start the MySQL server on my Windows system. When I tried in services.msc to run, I got this error:
Starting it through the XAMPP control panel does not work either:
Can you help me to solve this?
Open windows services (Start->run ->Services.MSC)
Find service with name "Mysql Server" and check path, it should be something like that:
"C:\Program Files (x86)\Parallels\Plesk\Databases\MySQL51\bin\mysqld.exe" "--defaults-file=C:\Program Files (x86)\Parallels\Plesk\Databases\MySQL\Data\my.ini" MySQL
Make sure that Mysql folder and executable file mentioned above exist by this path.
OR
Sometimes the file name of mysqld-nt.exe renamed to mysqld-nt.exe~ so rename it back to its original name and this may solve the problem.
Go to the path: C:Programs Files\MariaDB 10.2\data..
Lookout for my.ini file. Open the file and check the path for "datadir".
If that does not match to your installed directory then update it.
Your problem will be solved for sure.
I faced the same problem and solved it.
Just modify the registry editor value.
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/MySQL/ImagePath
I have installed Laravel and and I am playing around with it.
I am following the tutorial :-
http://geekanddummy.com/how-to-laravel-4-tutorial-part-3-using-external-libraries/
I need a new library and have added that in composer.json.
But when I run
php composer.phar update
I get the following message :-
Composer could not find a composer.json file in
What do I need to do to get this corrected..?
I'm the author of the tutorial you link to (hope our Laravel tutorial series is of some use, by the way). I can't quite tell from your answer whether you restored all the content of the original composer.json file when you created a new file of the same name...? You definitely shouldn't need to nuke the composer.json file and start again. As you probably know, that file contains all the Composer-based dependencies for your Laravel project, so you would of course lose significant functionality if you were to wipe it and leave anything out when you start again.
The error message looks to me like you're either in the wrong directory or it's a permissions problem with the composer.json file. It's too late to be certain now, but if you come across the problem again, try running:
chmod a+r composer.json
at the console/ssh shell before running composer update. This restores read permissions (for all users). You may also wish to check file ownership. (Both commands assume we're in a Unix/Linux system, so YMMV.)
Watch out also for instances where you're running a Composer command with the global parameter. This will cause an change that relates to wherever you've installed Composer, rather than the directory you're currently working in.
Note that you can also update using the --working-dir parameter, thus:
php composer.phar --working-dir=/path/to/laravel/project update
Hope this helps.
Rob
Deleting the existing composer.json after copying the content and then saving a new file with the same name works.
If your on windows (at least in my experience) you actually use just 'composer', not composer.phar/.json or any extension.
composer update
composer dump-autoload
This is all I need to type in to be able to access composer in my laravel directory.
i had the same issue, tried several many solutions that worked for others but not in my case.
then some-one told me to drop the 'php' and '.phar' from my command. i.e. directly use
composer update
composer create-project etc.etc.
and to my surprise it worked..
Occasionally, and for reasons that remain a bit vague, restarting the server seems to solve the issue. That step might be worth trying before making changes to file permissions.
Go to https://git-scm.com/download/win
Then download related version and run your composer command inside the git bash
Or else you can use vscode bash;
enter image description here
The Archiva documentation states:
The standalone installation of Archiva is capable of separating its configuration from installation
However, I didn't manage to do so with 1.3.6 and 1.4 (using Ubuntu 12.04).
$ARCHIVA_BASE is set to /var/archiva and exported, but the wrapper doesn't seem to take care of that and always launches in the installation directory.
Moreover, the 1.4 init script (bin/archiva) uses $BASEDIR instead of $ARCHIVA_BASE
Does someone have a clue?
Post is old but I faced this problem recently and wanted to share what worked for me to make Archiva 2.2.3 execute as a service on RHEL 6.8
Archiva installed at /opt/archiva
Archiva data directory created at /var/archiva_data using these instructions
Edited /opt/archiva/conf/wrapper.conf and made the following change
set.default.ARCHIVA_BASE=/var/archiva_data
Edited /opt/archiva/bin/archiva and made the following change
RUN_AS_USER=foo
Linked /etc/init.d/archiva with /opt/archiva/bin/archiva
Start service using service archiva start
How I do personally.
My archiva app installed in /x1/archiva/archiva with
archiva -> /x1/archiva/apache-archiva-1.4-M4-SNAPSHOT
And all datas archiva.xml in /x1/archiva/archiva-base
archiva start script is modified with:
BASEDIR=/x1/archiva/archiva/bin
BASEDIR_CONF="/x1/archiva/archiva-base"
WRAPPER_CONF="$BASEDIR_CONF/conf/wrapper.conf"
PIDDIR="$BASEDIR_CONF/logs"
And it works fine as it :-)
This post might be a little old, I'd nonetheless like to share my experience using Archiva 2.2.1. Seperating the base from the installation directory by simply setting $ARCHIVA_BASE (as described on http://archiva.apache.org/docs/1.4-M4/adminguide/standalone.html) still doesn't work. I did the following to get Archiva up and running:
My setup
Archiva binaries and installation files in /opt/archiva/current
(current being a symlink pointing to apache-archiva-2.2.1)
Directories conf/ data/ logs/ temp/ moved to /data/archiva_data
Adjustments in Archiva config files
File /opt/archiva/current/bin:
BASEDIR_CONFIG="/data/archiva_data"
WRAPPER_CONF="$BASEDIR_CONFIG/conf/wrapper.conf"
PIDDIR="$BASEDIR_CONFIG/logs"
Wrapper config File /data/archiva_data/conf/wrapper.conf:
#Manually set the Archiva Basedir
set.default.ARCHIVA_BASE=/data/archiva_data
So the steps pointed out by olamy did work, however a further adjustment was needed in the wrapper config file to reflect the configuration being moved away from the installation directory.
After the changes, I was able to start and use Archiva.
1 remember to use cp when you copy configuration files from original conf folder to your folder.
2 if you're trying to run archiva as service you need to modify wrapper.conf at line 14 with added your ARCHIVA_BASE folder.
I'm trying to create an RPM in Fedora 15 that will install my software, but in order for my software to work correctly once installed, I also need to edit other (configuration) files on the system, add users/groups, etc. Performing some of these tasks is only allowed by the root user. I know to never create an RPM as the root user, and I understand why that is such a bad idea. However, if I add shell script statements to my spec file (%post, %prep... any section) to edit the necessary files, add users/groups, etc., my rpmbuild command fails with message "Permission denied" (not surprisingly).
What's the best way to handle this? Do I have to tell my users to install my package first, and then perhaps run a shell script as root to configure it all? That doesn't seem very elegant. I was hoping to allow a user to do everything with one simple command such as 'yum install mysoftware'.
Much of my research suggests that perhaps this shouldn't even be done via RPM. I've read many parts of Maximum RPM, and lots of other good resources, but haven't found what I'm looking for. I'm new to creating RPMs, but have already been able to successfully create a simple spec file for my software... I just can't get everything configured properly after the package is unzipped and installed to the correct location. Any input is greatly appreciated!
useradd should be run in %pre and shouldn't run during rpmbuild. That's the standard way of doing it. I would recommend the packaging guidelines and specifically the section on users and groups.
The %pre section of your RPM .spec file should check for all the conditions necessary for your software to install.
The %post section of your RPM .spec file should make all the modifications needed for your software to run.
To avoid file permission errors in the %post section of your RPM .spec file, you can set the file permissions and ownership in the %files section. That way, the user who installs the RPM has the appropriate permissions to modify the configuration files.
%install
# Copy files to directories on your installation server
%files
# Set file permissions and ownership on your installation server
%attr(775, myuser, mygroup) /path/to/my/file
%pre
# Check if custom user 'myuser' exists. If not, create it.
# Check if custom group 'mygroup' exists. If not, create it.
# All other checks here
%post
# Perform post-installation steps here, like editing other (configuration) files.
echo "Installation complete."
I followed this tutorial to the very end, then found out it didn't work right. I think I have everything installed but when I type
mysql -uroot
I only get
-bash: mysql: command not found
Note: I did not skip the "Setting the Path" step. Upon running this command for the first time:
mate ~/.bash_login
This brought up an empty file. So I added this line:
export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"
I saved the file, closed TextMate, executed the following command:
. ~/.bash_login
...and continued with the tutorial. Based on your suggestions, I thought maybe the file didn't actually get saved. So I ran the following command to bring up the file again:
mate ~/.bash_login
...yet the contents of the file were as they should be.
Any suggestions?
You probably don't have the mysql binaries in your path.
The link you posted has a section on setting the path, titled "Setting the Path Do not skip this step! Most everything else will fail if you do."
EDIT: As debugging steps, try:
First launching a new terminal window. Does it run now?
Typing "echo $PATH" at the prompt. Does the path show up correctly as you've typed it in bash_profile?
Running it the long way: /usr/local/mysql/bin/mysql -u root
Does the application run?
Did you follow the step that says
Setting the Path
Do not skip this step! Most everything
else will fail if you do.
Did you close your terminal window and re-open it afterwards?
Update:
What does "which mysql" say? Does "ls /usr/local/mysql/bin" say?
Two things:
Try editing ~/.profile (rather than ~/.bash_profile or ~/.bash_login).
You may find it easier to use the native Mac style .dmg installer directly from Sun.
One nice thing about the dmg installer is that it automagically sets up symlinks to /usr/local/mysql (which means less - or no - fiddling with your $PATH).
Another option would be to use MAMP.
It has Apache, PHP and MySQL packaged with no further setup necessary.
MySQL is usually put in /usr/local/mysql/bin/
You need to add this to your PATH, you can do this by adding the follwoing lines to your .bash_profile
PATH=$PATH:/usr/local/mysql/bin/
export PATH
The .bash_profile file is located in the root of your username directory.
Make sure you restart your Terminal for the setting to take affect.
And if you're not a command-line person, I highly recommend you also install the MySQL Preference Pane to start/stop the server and install Sequel Pro to create databases and run queries.
ftp://ftp.mysql.com/pub/mysql/download/gui-tools/MySQL.prefPane-leopardfix.zip
http://www.sequelpro.com/