I am trying to export my application to another process management format/system (specifically, upstart). In doing so, I have come across a number of roadblocks, mostly due to lacking documentation.
As a non-root user, I ran the following command (as shown here):
-bash> foreman export upstart /etc/init
ERROR: Could not create: /etc/init
I "could not create" the directory due to inadequate permissions, so I used sudo:
-bash> sudo foreman export upstart /etc/init
Password:
ERROR: Could not chown /var/log/app to app
I "could not chown... to app" because there is no user named app.
Where is app coming from?
How should I use forman to export to upstart?
app is default for both the name of the app and the name of the user the application should be run as when the corresponding options (--app and --user) are not used. See the foreman man page for the available options, but note that at the time of this writing the official synopsis did not include [options]:
foreman export [options] <format> [location]
Example:
-bash> sudo foreman export --app foo --user bar upstart /etc/init
Password:
[foreman export] writing: foo.conf
[foreman export] writing: foo-web.conf
[foreman export] writing: foo-web-1.conf
[foreman export] writing: foo-worker.conf
[foreman export] writing: foo-worker-1.conf
Result:
-bash> l /etc/init/
total 80
drwxr-xr-x 12 root wheel 408 20 Oct 09:31 .
drwxr-xr-x 94 root wheel 3196 20 Oct 08:05 ..
-rw-r--r-- 1 root wheel 236 20 Oct 09:31 foo-web-1.conf
-rw-r--r-- 1 root wheel 41 20 Oct 09:31 foo-web.conf
-rw-r--r-- 1 root wheel 220 20 Oct 09:31 foo-worker-1.conf
-rw-r--r-- 1 root wheel 41 20 Oct 09:31 foo-worker.conf
-rw-r--r-- 1 root wheel 315 20 Oct 09:31 foo.conf
-bash> l /var/log/foo/
total 0
drwxr-xr-x 2 bar wheel 68 20 Oct 09:31 .
drwxr-xr-x 45 root wheel 1530 20 Oct 09:31 ..
Related
I have a fresh install of nextcloud 22.2.0, that I installed according to [these instructions:]1
After NC installation, I hae ZERO errors in my NC log. However, in the Overview section I have some basic wearnings that I know are "false positives" forllowing a new installation. There I want to run the NC occ in order to repair things:
./occ integrity:check-core
However, I get these errors:
Your data directory is invalid
Ensure there is a file called ".ocdata" in the root of the data directory.
Cannot create "data" directory
This can usually be fixed by giving the webserver write access to the root directory. See https://docs.nextcloud.com/server/22/go.php?to=admin-dir_permissions
Setting locale to en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 failed
Please install one of these locales on your system and restart your webserver.
An unhandled exception has been thrown:
Exception: Environment not properly prepared. in /web/lib/private/Console/Application.php:162
Stack trace:
#0 /web/console.php(98): OC\Console\Application->loadCommands(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#1 /web/occ(11): require_once('/web/console.ph...')
#2 {main}
I was able to resolve this error:
Setting locale to en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 failed
Please install one of these locales on your system and restart your webserver.
By using:
chattr -i /var/www/clients/client1/web19/
jk_cp -j /var/www/clients/client1/web19/ /usr/lib/locale
chattr +i /var/www/clients/client1/web19/
Can anyone tell me how to resolve the two remaining errors so that the NC occ will work correctly?
thanks
Also the user's permissions are correct:
# ls -la /var/www/clients/client1/web19
total 60
drwxr-xr-x 15 root root 4096 Nov 12 15:12 .
drwxr-xr-x 9 root root 4096 Nov 12 14:50 ..
lrwxrwxrwx 1 root root 7 Nov 12 15:09 bin -> usr/bin
drwxr-xr-x 2 web19 client1 4096 Nov 12 14:50 cgi-bin
drwxr-xr-x 2 root root 4096 Nov 12 17:36 dev
drwxr-xr-x 8 root root 4096 Nov 12 15:12 etc
drwxr-xr-x 4 root root 4096 Nov 12 15:12 home
lrwxrwxrwx 1 root root 7 Nov 12 15:09 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Nov 12 15:09 lib64 -> usr/lib64
drwxr-xr-x 2 root root 4096 Nov 12 19:58 log
drwx--x--- 2 web19 client1 4096 Nov 12 20:05 private
drwx------ 2 web19 client1 4096 Nov 12 15:09 .ssh
drwxr-xr-x 2 root root 4096 Nov 12 14:55 ssl
drwxrwx--- 2 web19 client1 4096 Nov 12 20:09 tmp
drwxr-xr-x 8 root root 4096 Nov 12 15:09 usr
drwxr-xr-x 4 root root 4096 Nov 12 15:12 var
drwx--x--x 14 web19 client1 4096 Nov 12 20:09 web
drwx--x--- 2 web19 client1 4096 Nov 12 14:50 webdav
I had the same problem as you and, curiously, I use the same user/client for the same service.
I've resolved in the following way (in addition to yours solution about "locale").
Go into the jail root (/var/www/clients/client1/web19). Here create the directories to contain PHP stuff:
mkdir -p etc/php/7.4/cli/conf.d
Copy the system-wide php.ini for cli into jail:
cp -a /etc/php/7.4/cli/php.ini etc/php/7.4/cli/php.ini
"Hardly" link every file *.so present in system-wide conf into the jail. For example:
ln /etc/php/7.4/mods-available/apcu.ini 20-apcu.ini
If you has the cache problems too (as me), you can add a definition before run occ.
I'm using the following command:
runuser -l web19 -c "cd /web; php --define apc.enable_cli=1 ./occ"
...and all seems to works fine! :-)
I'm getting status code 500 on my Dockerized Flask server.
I bashed into the container to check the logs:
docker exec -ti container_name /bin/bash
in /var/log I found:
root#b80b0c02fd18:/var/log# ls -al
total 224
drwxr-xr-x 1 root root 4096 Oct 13 21:02 .
drwxr-xr-x 1 root root 4096 Oct 12 07:00 ..
-rw-r--r-- 1 root root 9052 Oct 20 20:50 alternatives.log
drwxr-xr-x 1 root root 4096 Oct 20 20:49 apt
-rw-rw---- 1 root utmp 0 Oct 12 07:00 btmp
-rw-r--r-- 1 root root 164661 Oct 20 20:50 dpkg.log
-rw-r--r-- 1 root root 3232 Oct 12 07:00 faillog
-rw-rw-r-- 1 root utmp 29492 Oct 12 07:00 lastlog
-rw-rw-r-- 1 root utmp 0 Oct 12 07:00 wtmp
I couldn't cat or nano the files faillog nor lastlog so I don't know if the files
are relevant.
Where do I find access log or error log for containerized Flask server ?
docker logs <your container_name> to see the logs of the container
You can also find the logs for the flask app at /var/log/daemon.log
When I add a remote interpreter from one of my docker-compose, it doesn't seem to succeed and doesn't show any packages in the dialog. When I add an interpreter to the debugger it says:
python packaging tools not found.
Then if i click on install packaging tools, error displayed:
ERROR: for dockeryard_pycharm_helpers_1
Cannot start service pycharm_helpers: network not found
Starting dockeryard_postgres_1 ...
Starting dockeryard_nginx_1 ...
Starting dockeryard_redis_1 ...
Starting dockeryard_postgres_1 ...
Starting dockeryard_nginx_1 ...
Starting dockeryard_pycharm_helpers_1
Starting dockeryard_redis_1
Starting dockeryard_worker_1 ...
Starting dockeryard_worker_1
Starting dockeryard_pycharm_helpers_1
ERROR: for dockeryard_pycharm_helpers_1 Cannot start service pycharm_helpers: network not found
ERROR: for pycharm_helpers Cannot start service pycharm_helpers: network not found
[31m
ERROR [0m:
Note, this interpreter was already in use and I was able to connect remotely with PyCharm, but I have added and eventually removed a custom network to the container.
As explained in Configuring Remote Python Interpreters - "When a remote Python interpreter is added, at first the PyCharm helpers are copied to the remote host". And my guess something went wrong since network was updated in the docker-compose.
From what I understand from the error message, when PyCharm starts interpreter it tries to use/find that network c7b0cc277c94ba5f58f6e72dcbab1ba24794e72422e839a83ea6102d08c40452.
I don't see that network listed anywhere when I run:
$ docker network inspect dockeryard_default
So PyCharm stores it somewhere and not been updated with the change.
I have tried to remove interpreter (using PyCharm dialog) and add it back - same result.
How can I get rid of this network and make PyCharm to be able to debug again?
Thanks.
Was having a near identical error and was able to get past it. I did two things though I'm uncertain as to which was the actual solution:
Made sure the mappings were correct under both (a) Preferences -> Project -> Project Interpreter -> Path mappings and (b) Run -> Edit Configurations -> <Your_Configuration> -> Path mappings
Removed/deleted any containers that looked to be related to PyCharm (believe this is more than likely what solved things).
Hope this helps. PyCharm docker-compose seems to work for some and be a real PITA for others.
One other note. I downgraded from PyCharm 2018 to 2017.3 as there's known docker bugs in 2018.
EDIT: And it would seem a docker-compose down from CLI reintroduces the error -_-
TLDR:
The {project_name}_pycharm_helpers_{pycharm_build_number} volume has been removed or is corrupted.
To repopulate it, run:
docker volume rm {project_name}_pycharm_helpers_{pycharm_build_number}
docker run -v {project_name}_pycharm_helpers_{pycharm_build_number}:/opt/.pycharm_helpers pycharm_helpers:{pycharm_build_number}
The pycharm_build_number can be found in the about section of your pycharm (mac OS: Pycharm > About)
Long story
I struggled a lot with PyCharm suddenly not finding the helpers any more or any related bugs, sometimes because I was clearing my containers or volumes. For instance, running
docker rm -f `docker container ps -aq`
docker volume rm $(docker volume ls -q)
will almost surely get pycharm into troubles.
AFAIK about how PyCharm works, there is:
a PyCharm base image named pycharm_helpers with tag corresponding to your pycharm build number (for example: PY-202.7660.27)
the first time you create docker related things, PyCharm creates volumes that get data from this image for later use in your containers. For instance, after a first attempt at running a remote docker-compose interpreter, I see the newly created myproject_pycharm_helpers_PY-202.7660.27 volume when doing docker volume ls.
when running the docker interpreter, PyCharm adds this volume into the /opt/.pycharm_helpers directory by adding at some point a -v myproject_pycharm_helpers_PY-202.7660.27:/opt/.pycharm_helpers to your command. For instance using docker-compose, you can see the addition of the -f /Users/clementwalter/Library/Caches/JetBrains/PyCharm2020.2/tmp/docker-compose.override.1508.yml and when you actually look into this file you see:
version: "3.8"
services:
local:
command:
- "python"
- "/opt/.pycharm_helpers/pydev/pydevconsole.py"
- "--mode=server"
- "--port=55824"
entrypoint: ""
environment:
PYCHARM_MATPLOTLIB_INTERACTIVE: "true"
PYTHONPATH: "/opt/project:/opt/.pycharm_helpers/pycharm_matplotlib_backend:/opt/.pycharm_helpers/pycharm_display:/opt/.pycharm_helpers/third_party/thriftpy:/opt/.pycharm_helpers/pydev"
PYTHONUNBUFFERED: "1"
PYTHONIOENCODING: "UTF-8"
PYCHARM_MATPLOTLIB_INDEX: "0"
PYCHARM_HOSTED: "1"
PYCHARM_DISPLAY_PORT: "63342"
IPYTHONENABLE: "True"
volumes:
- "/Users/clementwalter/Documents/myproject:/opt/project:rw"
- "pycharm_helpers_PY-202.7660.27:/opt/.pycharm_helpers"
working_dir: "/opt/project"
volumes:
pycharm_helpers_PY-202.7660.27: {}
You get into troubles when this volume is not correctly populated anymore.
Fortunately the docker volume documentation has a section "Populate a volume using a container" which is exactly what PyCharm does under the hood.
For the record you can check the content of the pycharm_helpers image:
$ docker run -it pycharm_helpers:PY-202.7660.27 sh
/opt/.pycharm_helpers #
you end up into the pycharm_helpers directory and find all the helpers here:
/opt/.pycharm_helpers # ls -la
total 5568
drwxr-xr-x 21 root root 4096 Dec 17 16:38 .
drwxr-xr-x 1 root root 4096 Dec 17 11:07 ..
-rw-r--r-- 1 root root 274 Dec 17 11:07 Dockerfile
drwxr-xr-x 5 root root 4096 Dec 17 16:38 MathJax
-rw-r--r-- 1 root root 2526 Sep 16 11:14 check_all_test_suite.py
-rw-r--r-- 1 root root 3194 Sep 16 11:14 conda_packaging_tool.py
drwxr-xr-x 2 root root 4096 Dec 17 16:38 coverage_runner
drwxr-xr-x 3 root root 4096 Dec 17 16:38 coveragepy
-rw-r--r-- 1 root root 11586 Sep 16 11:14 docstring_formatter.py
drwxr-xr-x 4 root root 4096 Dec 17 16:38 epydoc
-rw-r--r-- 1 root root 519 Sep 16 11:14 extra_syspath.py
drwxr-xr-x 3 root root 4096 Dec 17 16:38 generator3
-rw-r--r-- 1 root root 8 Sep 16 11:14 icon-robots.txt
-rw-r--r-- 1 root root 3950 Sep 16 11:14 packaging_tool.py
-rw-r--r-- 1 root root 1490666 Sep 16 11:14 pip-20.1.1-py2.py3-none-any.whl
drwxr-xr-x 2 root root 4096 Dec 17 16:38 pockets
drwxr-xr-x 3 root root 4096 Dec 17 16:38 profiler
-rw-r--r-- 1 root root 863 Sep 16 11:14 py2ipnb_converter.py
drwxr-xr-x 3 root root 4096 Dec 17 16:38 py2only
drwxr-xr-x 3 root root 4096 Dec 17 16:38 py3only
drwxr-xr-x 7 root root 4096 Dec 17 16:38 pycharm
drwxr-xr-x 4 root root 4096 Dec 17 16:38 pycharm_display
drwxr-xr-x 3 root root 4096 Dec 17 16:38 pycharm_matplotlib_backend
-rw-r--r-- 1 root root 103414 Sep 16 11:14 pycodestyle.py
drwxr-xr-x 24 root root 4096 Dec 17 16:38 pydev
drwxr-xr-x 9 root root 4096 Dec 17 16:38 python-skeletons
drwxr-xr-x 2 root root 4096 Dec 17 16:38 rest_runners
-rw-r--r-- 1 root root 583493 Sep 16 11:14 setuptools-44.1.1-py2.py3-none-any.whl
-rw-r--r-- 1 root root 29664 Sep 16 11:14 six.py
drwxr-xr-x 3 root root 4096 Dec 17 16:38 sphinxcontrib
-rw-r--r-- 1 root root 128 Sep 16 11:14 syspath.py
drwxr-xr-x 3 root root 4096 Dec 17 16:38 third_party
drwxr-xr-x 3 root root 4096 Dec 17 16:38 tools
drwxr-xr-x 5 root root 4096 Dec 17 16:38 typeshed
-rw-r--r-- 1 root root 3354133 Sep 16 11:14 virtualenv-16.7.10-py2.py3-none-any.whl
to make these helpers available again, following the docker documentation, you have to fix the volume. To do so:
docker rm {project_name}_pycharm_helpers_{pycharm_build}
docker run -v {project_name}_pycharm_helpers_{pycharm_build}:"/opt/.pycharm_helpers" pycharm_helpers:{tag}
et voilà
If you're still seeing this in PyCharm 2020.2 then do this:
close PyCharm
try #peterc's suggestion:
docker ps -a | grep -i pycharm | awk '{print $1}' | xargs docker rm
launch PyCharm again
The option invalidate cache -> Clear downloaded shared indexes will also repopulate the Pycharm volumes. (At least in 2021.1)
I can upload video less than 100M via EC2 to S3. But when I try to upload file more then 100M I have this problem:
The tail of production.rb:
[dbe91a4c-0c42-48c2-8165-ae9f71cc39c4] Command :: file -b --mime '/tmp/RackMultipart20180220-14826-1x1yb8.mp4'
[dbe91a4c-0c42-48c2-8165-ae9f71cc39c4] [paperclip] Trying to link /tmp/RackMultipart20180220-14826-1x1yb8.mp4 to /tmp/b93945416b51d7b7076bcf9f697819dd20180220-14826-5mkak1.mp4
[dbe91a4c-0c42-48c2-8165-ae9f71cc39c4] [paperclip] Trying to link /tmp/b93945416b51d7b7076bcf9f697819dd20180220-14826-5mkak1.mp4 to /tmp/1c3b7d3617b75c8c2177c1dfde03e9ce20180220-14826-kklptr.mp4
[dbe91a4c-0c42-48c2-8165-ae9f71cc39c4] Command :: file -b --mime '/tmp/1c3b7d3617b75c8c2177c1dfde03e9ce20180220-14826-kklptr.mp4'
[dbe91a4c-0c42-48c2-8165-ae9f71cc39c4] (0.1ms) BEGIN
[dbe91a4c-0c42-48c2-8165-ae9f71cc39c4] [paperclip] Trying to link /tmp/b93945416b51d7b7076bcf9f697819dd20180220-14826-5mkak1.mp4 to /tmp/1c3b7d3617b75c8c2177c1dfde03e9ce20180220-14826-bw0wgm.mp4
[dbe91a4c-0c42-48c2-8165-ae9f71cc39c4] Command :: file -b --mime '/tmp/1c3b7d3617b75c8c2177c1dfde03e9ce20180220-14826-bw0wgm.mp4'
[dbe91a4c-0c42-48c2-8165-ae9f71cc39c4] (0.1ms) ROLLBACK
[dbe91a4c-0c42-48c2-8165-ae9f71cc39c4] Rendering videos/new.slim within layouts/application
And in file /tmp/
total 809304
drwxrwxrwt 8 root root 4096 Feb 20 13:15 ./
drwxr-xr-x 23 root root 4096 Feb 13 14:54 ../
-rw------- 4 ubuntu ubuntu 133547466 Feb 20 13:09 1c3b7d3617b75c8c2177c1dfde03e9ce20180220-14826-bw0wgm.mp4
-rw------- 4 ubuntu ubuntu 133547466 Feb 20 13:09 1c3b7d3617b75c8c2177c1dfde03e9ce20180220-14826-kklptr.mp4
-rw------- 4 ubuntu ubuntu 133547466 Feb 20 13:09 b93945416b51d7b7076bcf9f697819dd20180220-14826-5mkak1.mp4
drwxrwxrwt 2 root root 4096 Feb 13 14:54 .font-unix/
-rwx------ 1 ubuntu ubuntu 93 Feb 20 12:04 git-ssh-where-film-production-dunice.sh*
drwxrwxrwt 2 root root 4096 Feb 13 14:54 .ICE-unix/
-rw------- 1 ubuntu ubuntu 279808355 Feb 20 12:50 puma20180220-11196-cyloww
-rw------- 1 ubuntu ubuntu 14679270 Feb 20 12:50 RackMultipart20180220-11196-1t5jbyk.mp4
-rw------- 4 ubuntu ubuntu 133547466 Feb 20 13:09 RackMultipart20180220-14826-1x1yb8.mp4
drwx------ 3 root root 4096 Feb 14 06:41 systemd-private-8b23ec1f7e8644498bf0091b6fd675d2-systemd-timesyncd.service-xl7iRW/
drwxrwxrwt 2 root root 4096 Feb 13 14:54 .Test-unix/
drwxrwxrwt 2 root root 4096 Feb 13 14:54 .X11-unix/
drwxrwxrwt 2 root root 4096 Feb 13 14:54 .XIM-unix/
I upload files via Paperclip. Locally it works without problem.
This command
file -b --mime '/tmp/1c3b7d3617b75c8c2177c1dfde03e9ce20180221-12338-1xbpmbo.mp4'
return this:
application/octet-stream; charset=binary
Did you check storage space or free RAM?
df -h --total or free -m
also check this answer
Another place is to check your server's nginx configuration.
Look for client_max_body_size in nginx.conf
Disclaimer: This is part of your server's configuration and not a part of your Rails application.
I'm trying to get a bare bones Rails app deployed under Apache, Passenger 3.0.0 and Rails 3.0.3. I'm getting all kinds of weird errors. mostly revolving around what I think is related to bundler or RAILS_ENV.
Only non-default thing about the app is that development & test environments use SQLite3 and production uses MySQL.
When hitting app from web browser Passenger is throwing errors regarding gems (sqlite3) that are specifically (in the Gemfile AND in the database.yml) declared as NOT part of the production environment.
How can I tell what user the server is trying to run my Rails app as? I would like to make sure the RAILS_ENV is set correctly for that user as I think Passenger is trying to run this app in development mode for some reason.
Edit: added results of ps aux | grep httpd
myserver:current elvis$ ps aux | grep httpd
elvis 4424 0.4 0.0 66152 192 s000 S+ 11:03AM 0:00.00 grep httpd
_www 1950 0.0 0.2 93024 2544 ?? S 11:40PM 0:01.23 /usr/sbin/httpd -D FOREGROUND
root 1918 0.0 1.0 93024 10244 ?? Ss 11:39PM 0:02.75 /usr/sbin/httpd -D FOREGROUND
_www 4084 0.0 0.2 93024 2536 ?? S 9:41AM 0:00.15 /usr/sbin/httpd -D FOREGROUND
and ls -l ...
myserver:current elvis$ ls -l config
total 48
-rw-rw-r-- 1 aaron admin 1923 Nov 19 21:40 application.rb
-rw-rw-r-- 1 aaron admin 326 Nov 19 21:40 boot.rb
-rw-rw-r-- 1 aaron admin 741 Nov 19 21:40 database.yml
-rw-rw-r-- 1 aaron admin 1257 Nov 19 21:40 deploy.rb
-rw-rw-r-- 1 aaron admin 149 Nov 19 21:40 environment.rb
drwxrwxr-x 5 aaron admin 170 Nov 19 21:40 environments
drwxrwxr-x 7 aaron admin 238 Nov 19 21:40 initializers
drwxrwxr-x 3 aaron admin 102 Nov 19 21:40 locales
-rw-rw-r-- 1 aaron admin 1808 Nov 19 21:40 routes.rb
By default, passenger will run your app as the user who owns the config/environment.rb or config.ru file, see http://www.modrails.com/documentation/Users%20guide%20Apache.html#user_switching
Passenger will run in the production environment by default unless you tell it otherwise with the RailsEnv, see http://www.modrails.com/documentation/Users%20guide%20Apache.html#rails_env
You could run ps aux | grep httpd to see what user is running your apache process.
That's what I use to detect what user should run the rails app
RAILS_USER=$(stat -c '%U' /YOUR_PATH/environment.rb)
echo "Detected rails user: $RAILS_USER"