Currentl I'm facing an issue where I would like to redirect stdout/stderr to specific log files. I have a created a service file for systemd service where I have added the steps for redirection, which is not working because current version 219 of systemd on the system does not support it and would require v240+ to work. My machine is CentOS 7.7.
Service file:
=============
[Unit]
Description=Process Monitoring and Control Daemon
After=rc-local.service nss-user-lookup.target
[Service]
User=jams
#Type=forking
WorkingDirectory=/opt/workspace/Dashboard/source-code/dashboard/
ExecStart=/opt/workspace/.env/bin/python kafka_consumer.py
StandardOutput=append:/data/dashboard/access.log
StandardError=append:/data/dashboard/error.log
Restart=always
[Install]
WantedBy=multi-user.target
$ systemctl --version
systemd 219
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
$ cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
Sorry, I'm not much familiar and have very less knowledge about this. Is it possible to upgrade the version of systemd to v240 or higher on CentOS 7.7 ? If yes, could anyone please point me in the right direction to get the source code and with the steps to build the package ?
Or, any alternatives ?
I see the question is rather old, but if you are still searching for a solution then something like this could work:
ExecStart=/opt/workspace/.env/bin/python kafka_consumer.py >> /data/dashboard/access.log 2>>/data/dashboard/error.log
A similar solution works for me for a similar problem on CentOS 7 with systemd 219.
Related
I tried to build a gdb for esp32 that works with qemu, but after many attempt, I didn't manage. All my attempts leaded me to the following error message after connecting to the remote target: Remote 'g' packet reply is too long.
Right now I am using the prebuilt version from Ebiroll: https://github.com/Ebiroll/qemu_esp32/blob/master/bin/xtensa-esp32-elf-gdb
but I would like to use a newer gdb version than 7.10, did anyone had success with this?
Here is how I built gdb:
git clone --depth 1 --branch esp-2021r2-gdb https://github.com/espressif/binutils-gdb.git
cd binutils-gdb
mkdir -p build
cd build
../configure --without-guile --host=x86_64-pc-linux-gnu --target=xtensa-esp32-elf --disable-werror
make
make install
(note from this branch the patch to apply from the Zephyr project, as described here https://github.com/Ebiroll/qemu_esp32#qemu-esp32, seems to already be included)
I also tried by applying the following patch (no success):
curl -L https://raw.githubusercontent.com/Ebiroll/gdb/master/gdb/xtensa-config.c.qemu --output binutils-gdb/gdb/xtensa-config.c
or patching qemu to fix the value of num_regs (tried 104 and 172, also no success).
Espressif's qemu wiki mentions setting an environment variable to only list the core registers:
export QEMU_XTENSA_CORE_REGS_ONLY=1
This needs to be set in the environment from where qemu will be executed.
My recommendation is to use both qemu and gdb (from the Esp32 tool chain) as provided by Espressif. I have recently used this combination with success. The latest release uses gdb 9.2.
I am trying to run a Docker image based on an ARMv7 container on a x86 computer. According to this site, it is possible by running this container first.
docker run --rm --privileged hypriot/qemu-register
This command works on Mac OS X and on an Ubuntu 19 virtual machine (with a Windows 10 host). However, when I try to run on CentOS 7 and one of the AWS A1 instances, I get the message standard_init_linux.go:211: exec user process caused "exec format error". The CPU for the CentOS 7 is an Intel Core i7-8700K and AWS A1 is based on the Graviton processor.
Anyone know what I'm missing here?
The complaint on the AWS A1 instance is with installing miniconda. I'm not sure if there is a way to say yes (to continue to install) since the -b flag already is supposed to get miniconda to install silently.
Step 6/11 : RUN /bin/bash /tmp/miniconda.sh -b -p /opt/miniconda
---> Running in ab9b5fef6837
WARNING:
Your processor does not appear to be an armv7l. This software
was sepicically build for the Raspberry Pi 2 running raspbian wheezy
(or above).
Are sure you want to continue the installation? [yes|no]
[no] >>> Aborting installation
AWS A1 instances do support running Armv7 binaries. Using the available Ubuntu 18.04 AMI for A1, run this on the command line:
cat /boot/config-4.15.0-1043-aws | grep "CONFIG_COMPAT=y"
If this succeeds, then the AMI and kernel have been built with support for running 32-bit executables on the 64-bit platform. To test this capability, install using apt-get install gcc:armhf libc6:armhf to get a minimal 32-bit build environment, create an executable and execute readelf -h on it. You should see the Machine listed as ARM, not AArch64. Execution should also succeed.
Testing docker with armv7 images also works out of the box on the Ubuntu 18.04 AMI on A1. I tested via docker pull armhf/ubuntu:latest and then entered interactive mode using bash and tried installing Miniconda3. The problem does appear to be with the Miniconda install script linked above. It tries this unconditionally on line 58:
if [[ `uname -m` != 'armv7l' ]]; then
echo -n "WARNING:
Your processor does not appear to be an armv7l. This software
was sepicically build for the Raspberry Pi 2 running raspbian wheezy
(or above).
Are sure you want to continue the installation? [yes|no]
[no] >>> "
read ans
if [[ ($ans != "yes") && ($ans != "Yes") && ($ans != "YES") &&
($ans != "y") && ($ans != "Y") ]]
then
echo "Aborting installation"
exit 2
fi
fi
Docker does not do any rewriting of what uname -m returns, it will see AArch64 on the A1 instance and it will trip up there. Commenting this block out should get you going on the A1 instances.
For getting this to work on your x86 laptop, you will need to copy qemu-arm-static to the docker image to enable emulation. I am not sure, but I would suspect that uname would still not return the proper machine-type Miniconda expects.
I did compile Ignite Application successfully.
but The Binary didn't work.
/tmp/tmp.Nw0IPD6ru3/cmake-build-debug-local-container/planet_engine: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory
how can I make to it work?
Also, I compiled C++ Examples successfully. such as ignite-compute-example.
and, I execute that but I got an error message.
An error occurred: JVM library is not found (did you set JAVA_HOME environment variable?)
and I using a nightly release version 2.8.0.20190213 because I couldn't build to version 2.7 in my environment.
I posted environment values down.
IGNITE_HOME=
TERM=xterm-256color
SHELL=/bin/bash
LIBRARY_PATH=/root/jre1.8.0_201/lib/amd64/server:/root/jre1.8.0_201/lib/amd64/
LC_NUMERIC=ko_KR.UTF-8
SSH_TTY=/dev/pts/0
JRE_HOME=/root/jre1.8.0_201
USER=root
LS_COLORS=rs=0:d...
LD_LIBRARY_PATH=/root/jre1.8.0_201/lib/amd64/server:/root/jre1.8.0_201/lib/amd64/
CLASS_PATH=/root/jdk-11.0.2/lib:
LC_TELEPHONE=ko_KR.UTF-8
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/jdk-11.0.2/bin
LC_IDENTIFICATION=ko_KR.UTF-8
JAVA_HOME=/root/jdk-11.0.2
LANG=en_US.UTF-8
LC_MEASUREMENT=ko_KR.UTF-8
JDK_HOME=/root/jdk-11.0.2/lib
SHLVL=1
HOME=/root
LOGNAME=root
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
LC_TIME=ko_KR.UTF-8
LC_NAME=ko_KR.UTF-8
_=/usr/bin/env
Thank you for reading. :)
I got it.
I am working on a docker container environment.
and therefore I am using remote build and debug with ssh and gdb.
finally, I found out why it couldn't find libjvm.so and why couldn't read environment values such as JAVA_HOME.
because it is working in gdb for now.
I confirmed that it is working when without gdb.
I will find a solution.
and, if I have been found, I will update the answer.
[Solved]
I share how I make solved that.
I was using an Oracle JDK-11 through source install.
but Ignite C++ client need something different with latest released jdk versions.
Ignite need a directory structure like this
JAVA_HOME/ (as JDK install directory)
- jre/
- lib/
- lib/
...
I solved by apt install openjdk-8-jdk.
openjdk-8-jdk have structure for what Ignite need.
i added JAVA_HOME, IGNITE_HOME, at /etc/environment.
It works finally.
but I got another problem. HAHA
I am so sad.
This also GDB problem..
When I run make run.byte I get this error ocsigenserver: ocsigen:main: Fatal - You are not allowed to use port 80.. I've tried sudo make run.byte but sudo doesn't know about opam or ocsigenserver. I've tried to play with wwwuser in the Makefile.options, but I can't make it work.
The README generated by the distillery doesn't give much information, and I can't find anything online.
make test.byte works just fine.
Any idea please?
edit:
It looks like it has nothing to do with eliom/ocaml, non root users just can't run anything on ports lower than 1024 on Ubuntu. But I still don't understand why the distillery suggests that I can do it if my wwwuser is me, I don't think there's any way this is ever going to work.
I also don't understand how I am supposed to run sudo make run.byte, opam is installed in my ~ directory, sudo cannot find ocsigenserver.
I could make it work by running everything as root, but anytime I run an opam command as root I get the you shouldn't use opam as root warning. I don't think this is the way I'm supposed to run it. Something's not right.
With previous release of eliom (eliom.5.0.0) - I have not used yet the fresh 6.0.0 release - you have to install first your eliom application :
sudo make install
Then you have to kill the process listening to the 80/tcp port (ex: sudo netstat -tulpn 80 | grep :80 will help identify the process listening to that port - most likely apache2 or lighthttpd).
Then, you run your executable:
sudo PATH=$PATH OCAMLPATH=$OCAMLPATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH
make run.byte
This is what is written in README created with eliom-distillery - but take care to set your env variables before :
OCAMLPATH is the location of ocaml used in your env (in my env :~/.opam/4.02.3/bin).
LD_LIBRARY_PATH : .opam/4.02.3/lib/stublibs (otherwise dllssl_threads_stubs is not found)
I did the following both on Ubuntu 14 and SUSE Linux Enterprise Server 11 (x86_64) where libcgroup is installed, with root:
cgcreate -t ngam:home -a ngam:home -g cpuset:/nadav2ndCpuSet
cgset -r cpuset.cpus=1 nadav2ndCpuSet
After that, if you cat /sys/fs/cgroup/cpuset/nadav2ndCpuSet/cpuset.cpus,
you will get:
1
which is good! as it is supposed to work.
Then, from user ngam, I ran the following cmd:
cgexec -g cpuset:nadav2ndCpuSet ~/whileLoop
where whileLoop is just a simple program that runs in a loop doing sqrt.
After that, I got the following error msg:
cgroup change of group failed
Why is it happening?
Thanks!
I ran into something similar while playing with cgroups on Ubuntu 16.04 just now.
When using the controller cpuset, cpus and mems are not initiated. Therefor you manually have to do it. Since you already specified cpuset.cpus you only need to set cpuset.mems
simply running
echo 0 > /sys/fs/cgroup/cpuset/nadav2ndCpuSet/cpuset.mems
or
cgset -r cpuset.mems=0 nadav2ndCpuSet
would solve your problem.
for more info on cpuset see http://man7.org/linux/man-pages/man7/cpuset.7.html
What I found is I forgot to make cgconfig start with system reboot, so a simple systemctl start cgconfig resolve the problem, and then do not forget systemctl enable cgconfig to make it start with system reboot.
I know my this answer might not be relevant to the question. I hope when people search the error cgroup change of group failed, this answer could help them.
BTW: systemctl start cgconfig is for centos 7, for centos 6 you may use service cgconfig start / chkconfig cgconfig on