I'm using this article as a source to get me half way there, but I cannot figure out how to run supervisor with a custom config file path.
When I want to run supervisor manually, I just do:
supervisord -c /home/test/_app/supervisord.conf
When I implemented the auto start up script, it runs the default supervisor config file which is located in /etc/ directory. I don't want to use that one because it separates it from the core project folder and makes it hard to maintain and keep track of.
Try this:
In /etc/rc.d/init.d/supervisord, add prog_opts variable like this:
prog_opts=" -c /home/test/_app/supervisord.conf"
prog_bin="${exec_prefix}/bin/supervisord"
Then in start() function, change the call to:
daemon $prog_bin --pidfile $PIDFILE -- $prog_opts
I was able to fix this issue by simply deleting the default supervisord.conf file and then making a sym link with that default location and my custom conf file path.
Related
I'd need to add a Restart statement within a default .service file, and was looking to an alternate solution to replacing the .service file with a custom one (which works).
The idea would be just adding the following "delta" requirement in a, e.g., ${systemd_system_unitdir}/my_service.d/override.conf file:
[Service]
Restart=always
and then adding that file in a dedicated .bbappend recipe file.
Tests so far were not successful in adding the above statements in the deployed service file (despite the "delta" conf file being correctly deployed). Is this even a possible solution?
You should be able to do that simply by echoing that entry in a do_install:append() section in you .bbappend file. Something like:
do_install:append() {
echo "[Service]\nRestart=always" >> ${D}${sysconfdir}/wpa_supplicant/...
}
You can equally use sed to find and replace that section if there is already a file inplace.
${sysconfdir} will expanded to /etc. Check this file for more defined path variables: https://git.yoctoproject.org/poky/plain/meta/conf/bitbake.conf?h=blinky
Buildroot 7d43534625ac06ae01987113e912ffaf1aec2302 post 2018.02, Ubuntu 17.10 host.
I run:
make qemu_x86_64_defconfig
printf 'BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=\"kdb\"\n' >>.config
make olddefconfig
time make BR2_JLEVEL="$(nproc)"
where kdb is a Linux kernel configuration that has CONFIG_KGDB=y.
Then as expected:
grep '^CONFIG_KGDB=y' ./output/build/linux-4.15/.config
has a match.
But then I want to try out a new kernel config, so I try:
sed -i 's/BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=kdb/BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=nokdb/'
where nokdb is a kernel config that has CONFIG_KGDB=n and then:
time make BR2_JLEVEL="$(nproc)" linux-reconfigure
However to my surprise, the kernel .config did not change, CONFIG_KGDB=y is still there.
Only if I do:
rm -f ./output/build/linux-4.15/.config
time make BR2_JLEVEL="$(nproc)" linux-reconfigure
Is there a better way to force the kernel .config to be regenerated, e.g. some other linux-* target?
I don't like this rm solution because it forces me to deal with "internal" paths inside output.
I'd expect linux-reconfigure to do that regeneration for me.
Analogous behavior if you turn BR2_TARGET_ROOTFS_INITRAMFS on and off, which affects the CONFIG_INITRAMFS_SOURCE option of the Linux kernel.
http://lists.busybox.net/pipermail/buildroot/2018-March/215817.html
The config files are checked for timestamps, so after you do:
touch kdb
touch nokdb
printf 'BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=\"kdb\"\n' >>.config
make olddefconfig
time make BR2_JLEVEL="$(nproc)"
kdb and nokdb have the same modified date, and the kernel does not get reconfigured on the next:
sed -i 's/BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=kdb/BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=nokdb/'
time make BR2_JLEVEL="$(nproc)" linux-reconfigure
But if you touch the new config file, it works, even without using the linux-reconfigure target explicitly:
touch nokdb
time make BR2_JLEVEL="$(nproc)"
Alternatively, if you just edit the used file instead of pointing to a new one, the configuration also gets updated as expected.
I want to copy a particular file using Makefile and then make this file executable. How can this be done?
The file I want to copy is a .pl file.
For copying I am using the general cp -rp command. This is done successfully. But now I want to make this file executable using Makefile
Its a bad practice to use cp and chmod, instead use install command.
all:
install -m 0777 hello ../hello
You can use -m option with install to set the permission mode, and even note that by using the install you will preserve not only the permission but also the owner of the file.
You can still use chmod accordingly but it would be a bad practice
all:
cp hello ../hello
chmod +x ../hello
Update: install vs cp
cp would simply copy files with current permissions, install not only copies, but also can change perms/ownership as arg flags. (This is what your requirement was)
One significant difference is that cp truncates the destination file and starts copying data from the source into the destination file. install, on the other hand, removes the destination file first.
This is significant because if the destination file is already in use, bad things could happen to whomever is using that file in case you cp a new file on top of it. e.g. overwriting an executable that is running might fail. Truncating a data file that an existing process is busy reading/writing to could cause pretty weird behavior. If you just remove the destination file first, as install does, things continue much like normal - the removed file isn't actually removed until all processes close that file.[source]
For more details check these,
install vs. cp; and mmap
How is install -c different from cp
I looked at logrotate.conf examples and everything in my /etc/logrotate.d directory. Nowhere was I able to find documentation on variables in these files.
I am trying to create a config file for rotating the logs of an application we are writing. I want to set the directory where logs are stored once, and then use it as a variable, like so:
my_app_log_dir=/where/it/is/deployed/logs
${my_app_log_dir}/*.log ${my_app_log_dir}/some_sub_dir/*.log {
missingok
# and so on
# ...
}
Is that possible?
You can achieve what you are looking for by implementing this kludge:
my-logrotate.conf ( NOTE: double quotes " are mandatory, also note that file names don't have to appear on the same line )
"*.log"
"some_sub_dir/*.log"
{
missingok
# and so on
# ...
}
Then the actual logrotate script - my-logrotate.sh
#!/bin/sh
set -eu
cd "${my_app_log_dir}"
exec logrotate /path/to/my-logrotate.conf
Now you can add logrotate.sh to your crontab.
You can use a bash "here document" to create a suitable config file on the fly, either at installation time or before running logrotate.
A bash script might look like this:
cat >rt.conf <<.
"${my_app_log_dir}/*.log" {
rotate 5
size 15k
missingok
}
.
logrotate rt.conf
Directly in the config file no (as far as my knowledge in logrotate goes).
Other solution:
Use the include option to include parts of the configuration file from a directory. This can help you if you have a package for your application, the package can leave a file in that directory containing only the entries for your app.
With logrotate 3.8.7,a test reveals that you can set and use variables in the pre-rotate and post-rotate script sections.
I tried this for a particular service log file.
postrotate
pid_file="/run/some_service/some_serviced.pid"
test -e "${pid_file}" && kill -s HUP $(cat "${pid_file}") || true
touch "${pid_file}.WAS_USED"
endscript
After running logrotate in force mode to ensure the log file was rotated and the post-rotate script executed, on looking in /run/some_service, there was an additional file "some_serviced.pid.WAS_USED", thus proving that the use of the variable worked.
As the title says, I'm trying to ftpsync changed tree to our dev web server. On committing I get this error:
post-commit hook failed (exit code 13)
with output: Cannot create syncfile
for time sync option at
/data/ftpsync/ftpsync.pl line 484.
I've tried looking at line 484 but Perl looks like a foreign language to me :)
What permissions do I need to set and where so that syncfile can be created?
It creates the file in the current directory, and as far as I can tell doesn't change directories before that point. The easiest thing to do would be to change directories to /tmp before starting the script (and specify a local directory in its args instead of using the default .).