Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
Using Ubuntu 16.04 LTS to deploy my python app. Configured everything and the app is running manually. I want to automate it with supervisor, I have installed supervisor and configured it. But if I run:
Supervisor config file:
; supervisor config file
[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod=0700 ; sockef file mode (default 0700)
[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log/supervisor ; ('AUTO' child log dir, default $TEMP)
; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket
; The [include] section can just contain the "files" setting. This
; setting can list multiple files (separated by whitespace or
; newlines). It can also contain wildcards. The filenames are
; interpreted as relative to this file. Included files *cannot*
; include files themselves.
[include]
files = /etc/supervisor/conf.d/*.conf
supervisorctl reread I end up with unix:///tmp/supervisor.sock no such file
But supervisord status is running,
Anyone having an idea, please.
Running this command sudo service supervisord restart solved my issue.
Some answers suggest re-installation, which is essentially doing this
Finally solved it by reinstalling supervisor after deleting all configuration files in /etc/supervisor/conf.d/ this did the trick.
I had the same problem. After reading the man supervisorctl manual I realized the default file is /etc/supervisord.conf which in ubuntu is at /etc/supervisor/supervisord.conf. I created a symlink using:
sudo ln -s /etc/supervisor/supervisord.conf /etc/supervisord.conf
This fixed my problem.
Reason of getting this: There is multiple reasons, what I found is that my supervisor was got corrupted due to the server going down continuously by power tripping.
solution: Remove the supervisor first and then reinstall it.
Steps:
sudo apt-get remove supervisor
sudo apt-get remove --auto-remove supervisor
sudo apt-get purge supervisor
sudo apt-get purge --auto-remove supervisor
Link for the above can be found here :
https://www.howtoinstall.co/en/ubuntu/trusty/supervisor?action=remove
The Ubuntu supervisor package (3.3.1-1.1) has the configuration file in /etc/supervisor/supervisord.conf.
For some reason (I don't know why) there appears to be another configuration file in /etc/supervisord.conf and supervisorctl prefers that file.
You can either define the configuration file location explicitly to supervisorctl:
sudo supervisorctl -c /etc/supervisor/supervisord.conf reread
or just remove /etc/supervisord.conf.
Probably one of the configuration files has syntax errors.
For instance, verify if [program] clause is missing
Remove each file on conf.d directory and restart supervisor to isolate the problematic file.
Related
Sorry if this is answered elsewhere, or requires a trick.
I have installed openCPU on an ubuntu xenial-16.04 instance. I'd like to lengthen the timelimit.post value as instructed in the /etc/opencpu/server.conf file. Trouble is I can't find it.
ubuntu#ip-x-x-x-x:/usr/lib/opencpu$ ls -a
. .. library rapache scripts
Maybe please check again to see if you don't find /etc/opencpu/server.conf in the expected directory - i.e. because, as above in your output of ls -la /etc/opencpu/, the server.conf file is listed being there. Note though the owner is root so take that into account when you try to open+edit the file.
I have several buckets mounted using the awesome riofs and they work great, however I'm at a loss trying to get them to mount after a reboot. I have tried entering in the following to my /etc/fstab with no luck:
riofs#bucket-name /mnt/bucket-name fuse _netdev,allow_other,nonempty,config=/path/to/riofs.conf.xml 0 0
I have also tried adding a startup script to run the riofs commands to my rc.local file but that too fails to mount them.
Any idea's or recommendations?
Currently RioFS does not support fstab. In order to mount remote bucket at the startup time, consider adding corresponding command line to your startup script (rc.local, as you mentioned).
If for some reason it fails to start RioFS from startup script, please feel free to contact developers and/or fill issue report.
If you enter your access key and secret access key in the riofs config xml file, then you should be able to mount this via fstab or an init.d or rc.local script ..
See this thread
EDIT:
I tested this myself and this is what I find. Even with the AWS access details specified in the config file, there is no auto-matic mounting at boot. But to access the system, all one needs to do is to issue mount /mount/point/in-fstab .. and the fstab directive would work and persist like a standard fstab mounted filesystem.
So, it seems the riofs system is not ready at that stage of the boot process when filesystems are mounted. That's the only logical reason I can find so far. This can be solved with an rc.local or init.d script that just issues a mount command (at the worst)
But riofs does work well, even as the documentation seems sparse. It is certainly more reliable and less buggy than s3fs ..
Thanks all,
I was able to get them auto-mounting from rc.local with the syntax similar to:
sudo riofs --uid=33 --gid=33 --fmode=0777 --dmode=0777 -o "allow_other" -c ~/.config/riofs/riofs.conf.xml Bucket-Name /mnt/mountpoint
Thanks again!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I have a very simple script that needs to run as su (root) without using a password.
Script
#!/bin/bash
cd /Applications/data_vis/
sudo chown -R Fabulous:admin .
I have decided to use permissions and visudo(8) to make it possible, for the script above to run with out a password.
Permissions
sudo chown root:wheel take_ownership.sh
sudo chmod 4755 take_ownership.sh
Extract from visudo file
# User privilege specification
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL
%Fabulous ALL=(ALL) NOPASSWD: /Applications/data_vis/take_ownership.sh,
%ALL ALL=NOPASSWD: /Applications/data_vis/take_ownership.sh
# Uncomment to allow people in group wheel to run all commands
%wheel ALL=(ALL) ALL
I have tried many variations and a lot of the questions on this sight. However I must be missing something as it is not obvious to what I am missing or doing incorrect.
Any practical specific solutions welcome. I am using a bash shell.
sudo is used to give non-root users root priviledges for a couple of tasks.
Supposing "take_ownership.sh" is the script, which contents is listed above, the
task of gaining root priviledges is doubled:
With sudo inside the script and by setting the script suid bit and setting the ownership
to root:wheel.
This isn't necessary.
In general for security reasons setuid scripts are to prevented.
Therefore a shell may prevent the execution of such script generally.
Another reason for the problem may unsufficient rights on /Applications/data_vis/.
for the user, who executs the script (if the setuid bit was cleared as suggested
above).
Reduce the script to
sudo chown -R Fabulous:admin /Applications/data_vis
Remove the setuid bit.
Execute the script as non-root-user.
If it fails, check with dmesg for kernel entries.
Furthermore from the sudo manpage (Linux):
There is no easy way to prevent a user from gaining a root shell if that user is allowed to
run arbitrary commands via sudo. Also, many programs (such as editors) allow the user to
run commands via shell escapes, thus avoiding sudo's checks. However, on most systems it is
possible to prevent shell escapes with the sudoers(5) plugin's noexec functionality.
It is not meaningful to run the cd command directly via sudo, e.g.,
$ sudo cd /usr/local/protected
since when the command exits the parent process (your shell) will still be the same. Please
see the EXAMPLES section for more information.
Running shell scripts via sudo can expose the same kernel bugs that make setuid shell
scripts unsafe on some operating systems (if your OS has a /dev/fd/ directory, setuid shell
scripts are generally safe).
I have just upgraded my development system to Fedora 18-Beta. Just after this, my Symfony 2 projects stopped working, stating that JMSSecurityExtraBundle is trying to run grep, which exits with non-success status code of 2.
It seems that the Fedora guys have changed some context defaults for the httpd package. According to /etc/selinux/targeted/contexts/files/file_contexts:
/var/www(/.*)?/logs(/.*)? system_u:object_r:httpd_log_t:s0
they have changed the default context of all files in any directory called logs under /var/www. As some vendor directories contain .git dirs, which eventually contain a directory called logs, they will be automatically labeled as httpd_log_t.
The solution to change this, is to issue this command:
# semanage fcontext -a -t httpd_sys_content_t '/var/www(/.*)?/\.git/logs(/.*)?'
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
The postfix alias looks like this:
%omitted%: "|/var/www/rails/redmine/extra/mail_handler/rdm-mailhandler.rb --url %omitted% --key %omitted%"
The bounce message returned says
"Command died with status 127"
and
"Command output: /usr/bin/env: ruby: No such file or directory"
I ran
sudo -u postfix /usr/bin/env ruby -v
and it returned
ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2009.10
So I assume the postfix user has ruby in its path.
I changed the shebang to /usr/local/bin/ruby and it works but I would prefer to have the code match the svn for the project I checked out.
Postfix manual local(8) says about pipe aliases:
The PATH environment variable is
always reset to a system-dependent
default path
It seems that /usr/local/bin/ is only in PATH when running interactive shell. You could tweak the PATH environment variable in your OS, but I think it's better to just change the alias to something like:
%omitted%: "|/usr/local/bin/ruby /var/www/rails/redmine/...
When you execute the command via sudo you still have your own environment, therefore your own path. Postfix's local program resets the PATH to a minimum (probably /bin and /usr/bin) when invoking an external program. You can use export_environment config parameter to set a different path. More information
So I assume the postfix user has ruby in its path.
No, it means that the user you issued the sudo with has ruby in its path. A simple sudo doesn't change the $PATH.
The simplest solution for your issue probably would be to just prepend the actual ruby to your script call, something like the following (assuming your ruby lives in /usr/bin/ruby).
%omitted%: "|/usr/bin/ruby /var/www/rails/redmine/extra/mail_handler/rdm-mailhandler.rb --url %omitted% --key %omitted%"