iam confused about setting Resources in postgres unit file. I setup the following files:
cat /etc/systemd/system/postgresql.service.d/50-BlockIOWeight.conf
[Service]
BlockIOWeight=10
cat /etc/systemd/system/postgresql.service.d/50-CPUShares.conf
[Service]
CPUShares=10
then i make:
systemctl daemon-reload
systemctl restart postgresql.service
now i thought i can get the actual values of the service via:
systemctl show postgres.service | grep CPUShares
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
Also the following gets nothing:
cat /sys/fs/cgroup/blkio/system.slice/postgresql.service/blkio.weight
cat: /sys/fs/cgroup/blkio/system.slice/postgresql.service/blkio.weight: Datei oder Verzeichnis nicht gefunden
But if i delete my configurations and restart service and then set property instant, i can cat the configuration in /sys/fs/ .... see here:
rm -rf /etc/systemd/system/postgresql.service.d/50-*
systemctl daemon-reload
systemctl restart postgresql.service
cat /sys/fs/cgroup/cpu,cpuacct/system.slice/postgresql.service/cpu.shares
cat: /sys/fs/cgroup/cpu,cpuacct/system.slice/postgresql.service/cpu.shares: Datei oder Verzeichnis nicht gefunden
systemctl set-property postgresql.service CPUShares=10 BlockIOWeight=10
cat /sys/fs/cgroup/cpu,cpuacct/system.slice/postgresql.service/cpu.shares
10
but systemd show shows still no cpushares value:
systemctl show postgres.service | grep CPUShares
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
also the files in /etc/systemd was created
ls -la /etc/systemd/system/postgresql.service.d/
insgesamt 16
drwxr-xr-x 2 root root 4096 Jul 4 08:28 .
drwxr-xr-x 19 root root 4096 Jul 3 11:47 ..
-rw-r--r-- 1 root root 27 Jul 4 08:28 50-BlockIOWeight.conf
-rw-r--r-- 1 root root 23 Jul 4 08:28 50-CPUShares.conf
so setting via set-property with running service works ? but after simple restart the service all is gone, although the configurations are still present in /etc/systemd/system/postgresql.service.d/
Whats wrong here ?
Related
Using steps provided here, I kicked off a CodeBuild with the following advanced options checked:
Enable session connection
Allow AWS CodeBuild to modify this service role so it can be used with this build project
The buildspec included a codebuild-breakpoint:
version: 0.2
phases:
pre_build:
commands:
- ls -al
- codebuild-breakpoint
- cd "${SERVICE_NAME}"
- ls -al
- $(aws ecr get-login)
- TAG="$SERVICE_NAME"
build:
commands:
- docker build --tag "${REPOSITORY_URI}:${TAG}" .
post_build:
commands:
- docker push "${REPOSITORY_URI}:${TAG}"
- printf '{"tag":"%s"}' $TAG > ../build.json
artifacts:
files: build.json
The build started and produced the following logs without pausing:
[Container] 2022/02/28 13:49:03 Entering phase PRE_BUILD
[Container] 2022/02/28 13:49:03 Running command ls -al
total 148
drwxr-xr-x 2 root root 4096 Feb 28 13:49 .
drwxr-xr-x 3 root root 4096 Feb 28 13:49 ..
-rw-rw-rw- 1 root root 1818 Feb 28 10:54 user-manager\Dockerfile
-rw-rw-rw- 1 root root 140 Feb 28 10:34 user-manager\body.json
-rw-rw-rw- 1 root root 0 Feb 28 10:54 user-manager\shared-modules\
-rw-rw-rw- 1 root root 4822 Feb 21 14:52 user-manager\shared-modules\config-helper\config.js
-rw-rw-rw- 1 root root 2125 Feb 21 14:52 user-manager\shared-modules\config-helper\config\default.json
-rw-rw-rw- 1 root root 366 Feb 21 14:52 user-manager\shared-modules\config-helper\package.json
-rw-rw-rw- 1 root root 9713 Feb 21 14:52 user-manager\shared-modules\dynamodb-helper\dynamodb-helper.js
-rw-rw-rw- 1 root root 399 Feb 21 14:52 user-manager\shared-modules\dynamodb-helper\package.json
-rw-rw-rw- 1 root root 451 Feb 21 14:52 user-manager\shared-modules\token-manager\package.json
-rw-rw-rw- 1 root root 13885 Feb 21 14:52 user-manager\shared-modules\token-manager\token-manager.js
-rw-rw-rw- 1 root root 44372 Feb 28 10:34 user-manager\src\cognito-user.js
-rw-rw-rw- 1 root root 706 Feb 28 10:34 user-manager\src\package.json
-rw-rw-rw- 1 root root 32734 Feb 28 10:34 user-manager\src\server.js
[Container] 2022/02/28 13:49:03 Running command codebuild-breakpoint
2022/02/28 13:49:03 Build is paused temporarily and you can use codebuild-resume command in the session to resume this build
[Container] 2022/02/28 13:49:03 Running command cd "${SERVICE_NAME}"
/codebuild/output/tmp/script.sh: 4: cd: can't cd to user-manager
My primary question is: Why didn't the build pause and session manager link become available?
Side-quest: The reason I'm trying to debug the session is to try to determine why the process can't CD to the user-manager folder (which clearly exists). Any ideas why?
TLDR: The image on the build machine was too old.
Main quest
The template specified aws/codebuild/ubuntu-base:14.04 as the CodeBuild image. Presumably that image pre-dated the Session Manager functionality (which requires a specific version of the SSM agent to be installed).
I update the agent to aws/codebuild/standard:5.0 and was able to successfully pause on the breakpoint and connect to the session.
Side quest
Once I connected I was able to investigate the cause of the inability to CD to the folder. I can confirm that Tim's shot in the dark was correct! All the entries were in fact files - no folders.
This QuickStart is the gift that keeps on giving! When/if I get all the issues resolved I'll submit a PR to update the project. Those interested in the cause of the file/folder issue can follow up there.
Side quest update
The strange flattening behaviour was due to creating the zip file on a Windows machine and unzipping it on a unix machine (the build agent uses an Ubuntu image). Just zipped it using 7-Zip and that did the job.
I am trying to logrotate my log files. Here is my configuration file:
/home/deploy/apps/production_app/current/log/*.log {
daily
missingok
rotate 52
compress
create 0644 deploy deploy
delaycompress
notifempty
sharedscripts
copytruncate
}
And this is result of
ll apps/production_app/current/log/
on my log files:
-rw-rw-r-- 1 deploy deploy 0 Jul 1 10:01 production.log
-rw-rw-r-- 1 deploy deploy 1124555 Jul 1 10:01 production.log.1
And when I run this command
logrotate -v /etc/logrotate.d/production_app
I get following:
error: error creating output file /var/lib/logrotate.status.tmp:
Permission denied
And here is permission on my log-rotate config file
lrwxrwxrwx 1 root root 67 Feb 25 2019 /etc/logrotate.d/production_app -> /home/deploy/apps/production_app/shared/config/log_rotation
please check whether the dir "var/lib" is readonly.
I have an issue where a few tools, Portainer for example, can't find the docker socket on AWS.
I have some setup scripts that were run to set various containers.
On MacOS, it works without problems.
On a CentOS box, no problem as well.
On CentOS / AWS, containers cannot connect to the docker socket.
I am talking about a local unsecured connection to /var/run/docker.sock
What could be different on AWS?
I can see the socket:
➜ run ls -ld /var/run/docker*
drwxr-xr-x 8 root root 200 Nov 27 14:04 /var/run/docker
-rw-r--r-- 1 root root 4 Nov 27 14:03 /var/run/docker.pid
srw-rw-r-- 1 root docker 0 Nov 27 14:03 /var/run/docker.sock
I am trying to set up uwsgi.service to run on systemd for Django 1.10 on Linode with Fedora 24.
/etc/systemd/system/uwsgi.service
[Unit]
Description=uWSGI Emperor
After=syslog.target
[Service]
ExecStart=/home/ofey/djangoenv/bin/uwsgi --ini /etc/uwsgi/emperor.ini
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all
[Install]
WantedBy=multi-user.target
This should then call,
/etc/uwsgi/emporer.ini
[uwsgi]
emperor = /etc/uwsgi/vassals
uid = www-data
gid = www-data
limit-as = 1024
logto = /tmp/uwsgi.log
I then use a symbolic link,
$ sudo ln -s /home/ofey/djangoForum/django.ini /etc/uwsgi/vassals/
to
/home/ofey/djangoForum/django.ini
[uwsgi]
project = djangoForum
base = /home/ofey
chdir = %(base)/%(project)
home = %(base)/djangoenv
module = crudProject.wsgi:application
master = true
processes = 2
socket = 127.0.0.1:3031
chmod-socket = 664
vacuum = true
I have restarted all with,
$ sudo systemctl daemon-reload
$ sudo systemctl restart nginx.service
$ sudo systemctl retart uwsgi.service
The last command gives,
Job for uwsgi.service failed because the control process exited with error code. See "systemctl status uwsgi.service" and "journalctl -xe" for details.
$ sudo systemctl status uwsgi.service
gives,
● uwsgi.service - uWSGI Emperor
Loaded: loaded (/etc/systemd/system/uwsgi.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Dec 07 23:56:28 ofeyspi systemd[1]: Starting uWSGI Emperor...
Dec 07 23:56:28 ofeyspi uwsgi[7834]: [uWSGI] getting INI configuration from /etc/uwsgi/emperor.ini
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Main process exited, code=exited, status=1/FAILURE
Dec 07 23:56:28 ofeyspi systemd[1]: Failed to start uWSGI Emperor.
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Unit entered failed state.
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Failed with result 'exit-code'.
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Service hold-off time over, scheduling restart.
Dec 07 23:56:28 ofeyspi systemd[1]: Stopped uWSGI Emperor.
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Start request repeated too quickly.
Dec 07 23:56:28 ofeyspi systemd[1]: Failed to start uWSGI Emperor.
I can not figure out why uwsgi.service will not run.
uwsgi runs when I don't go through systemd and instead use,
$ sudo --ini django.ini
The most likely reason for that is that Emperor is not able to:
create the .pid file to write the processID;
create the unix-socket files for the vassals (seems to be not your case, since you are using :3031 port);
write to the log file specified by --logto option (/tmp/uwsgi.log in your case).
This often happens when any of these files exist and are owned by another user (most likely, root) or are located in a directory to which the user starting the service is not able to write.
Systemd's status log is not very informative on this subject. So, the quickest way to identify the case is to run your ExecStart command from systemd's service not as root and to see the output:
$ /home/ofey/djangoenv/bin/uwsgi --ini /etc/uwsgi/emperor.ini
If the output shows that the problem is permission, try the following.
Since you are going to run your server on behalf of www-data user, as it has been suggested already, make sure you have:
[Service]
User=www-data
Group=www-data
RuntimeDirectory=uwsgi
in your systemd unit config. Then, make sure the .pid files and unix-socket files (if any) are created under that directory (i.e. under /run/uwsgi) by adding this to your vassals .ini files:
runtime_dir = /run/uwsgi
pidfile=%(runtime_dir)/%n.pid
# if you prefer using unix-socket instead of a port
socket = %(runtime_dir)/%n.sock
# trying to chmod-socket is useless with a port, by the way
chmod-socket = 664
The %n variable in the given example stands for the vassal's .ini file name without extension (see the full-list here).
Finally, make sure the --logto file specified in Emperor's and vassals' configs is writable by such.
Please note, if you run uwsgi --ini /etc/uwsgi/emperor.ini as root and then terminate the procecc with ctrl+D, it will leave the above-mentioned temp files existing and owned by root, which will prevent other owners (like www-data) from writing to them, until you delete the files or chown/chmod them again.
The uwsgi systemd docs advise adding RuntimeDirectory=uwsgi to your service file. Try adding that.
Also check /tmp/uwsgi.log to see if any logging was generated there.
Comment out KillSignal = SIGQUIT
It can cause problems, see http://uwsgi-docs.readthedocs.io/en/latest/Systemd.html
also causes issues on Centos 7
I've set up SSH to my AWS Elastic Beanstalk instance using
eb ssh --setup
and can successfully SSH to my environment. But I can't see my Web application. When I am connected I find myself in an empty directory (ec2-user) and when I
cd /home
I just see
drwx------ 3 ec2-user ec2-user 4096 Jan 15 21:37 ec2-user
dr-xr-xr-x 23 root root 4096 Jan 15 21:03 ..
drwxr-xr-x 3 root root 4096 Oct 22 23:29 .
Where is my Web application located?
Do $ sudo find / -name <insert main file name here> to find out.
For example:
$ sudo find / -name \*.php
/var/lib/tomcat8/webapps/ROOT/info.php
/var/lib/tomcat8/webapps/ROOT/index.php
/tmp/deployment/application/ROOT/info.php
/tmp/deployment/application/ROOT/index.php
Or, as you can see, in /var/lib/tomcat8/webapps/ROOT/
You will notice, it depends on the platform. Python for example:
$ sudo find / -name application.py
/opt/python/bundle/2/app/application.py
For anyone who doesn't want to wait for find /, I found my rails app at /var/app/ondeck before it successfully deployed and at /var/app/current after it succeeded.
When you ssh into your instance, you are in the ~ directory. Type in cd .. to go to the parent directory, which is home. Then cd .. again to get to the root directory. There you can find the var folder, which will contain your files, as the others on here have pointed out.
the content of your WAR is in /var/lib/tomcat8/webapps/ROOT resp. /usr/share/tomcat8/webapps/ROOT