I am using Ububtu 20.04 with Apache 2.4.41 and logrotate 3.14.0, which is supposed to be set up such that Apache restarts in the postrotate script. The restart isn't happening, which means that Apache is writing to the wrong log file, which then grows indefinitely (because it has a suffix .log.1 rather than .log).
The postrotate script in the default /etc/logrotate.d/apache2 file looks like this:
postrotate
if invoke-rc.d apache2 status > /dev/null 2>&1; then \
invoke-rc.d apache2 reload > /dev/null 2>&1; \
fi;
endscript
The problem is that the invoke-rc.d command isn't working. If I try it from the command line, the results look like this:
# invoke-rc.d apache2 status
invoke-rc.d: could not determine current runlevel
invoke-rc.d: policy-rc.d denied execution of status.
invoke-rc.d: emulating initscript action "status", returning "unknown"
#
Can anyone give any tips on how to resolve this? I don't really know anything about invoke-rc.d, what it does or how to configure it. Would a simpler script looking like this work OK?
postrotate
apachectl restart
endscript
Related
I'm trying to use the linux find command to show me the files in my current directory that have been modified in the last 24h. To test my command, I piped it to ls as below.
find . -maxdepth 1 -mtime -1 | xargs -I{} ls -lh {}
but this command displays all the files in my directory, some of which were modified last year. What am I missing here? I also tried -atime and -ctime options out of curiosity and got seemingly the same file list.
Many thanks for the advice!
In my case the issues was caused because I had the wrong system time on my raspberry.
This was because systemd-timesyncd.service was no longer running.
After:
sudo systemctl unmask systemd-timesyncd.service
sudo systemctl enable systemd-timesyncd.service
sudo reboot
the system time was correct again. Note that the pi needs to be connected to a network for this to work. And also, of course, past wrong file dates don't get fixed by this (duh).
I have a program running on armbian single board computer. The program starts with -b option during the startup of the system. I created this simple shell script
#!/bin/bash
#Myprog server start
sudo -b /home/myprog/myprog
This program is C written and it sometimes outputs some information with printf functions. But since it is started with -b option there's is noting in the console.
Now when I log in to the armbian via ssh with Putty I want to occasionally read the output of this program. Is it even possible?
Not exactly what you’re asking, but generally speaking it’s better practice to redirect output to a log file than to try to interactively look at the console output for a background app.
Something like:
sudo -b /home/prog/myprog >> /home/prog/log.txt 2>&1
Should do it.
Then view output with
tail -f /home/prog/log.txt
If it’s really important to you to run interactively without logs, I would suggest running it from within “screen” without backgrounding it.
screen
sudo /home/prog/myprog
Then ctrl-d to detach and let it run in background. screen -r to reattach.
I try to backup my kiwi tcms data following steps on web http://kiwitcms.org/blog/atodorov/2018/07/30/how-to-backup-docker-volumes-for-kiwi-tcms/. Some question need help.
Which type datas stored on kiwi_uploads? Shall I also use command "docker volume rm kiwi_uploads" then restore it? Did same as Backing up the database.
Some errors occurs as below when restore kiwi_uploads using "cat uploads.tar | docker exec -i kiwi_web /bin/tar -x". But even error occurs, login and find previous data ok, such as plan, runs, test case...Of cause, I restore kiwi_db_data successfully.
cat uploads.tar | docker exec -i kiwi_web /bin/tar -x
/bin/tar: This does not look like a tar archive
/bin/tar: Skipping to next header
/bin/tar: Exiting with failure status due to previous errors
3."cat database.json | docker exec -i kiwi_web /Kiwi/manage.py loaddata --format json -". No any parameter behind last -? missing or just as this.
1) kiwi_uploads is for all files that are uploaded (or attached) to documents like Test Plan, Test Case, etc.
The instructions in the blog should work for you. Usually there's no need to remove the volume but if you are restoring everything it doesn't really matter.
2) For the errors you have
/bin/tar: This does not look like a tar archive
so whatever file you ended up with is not a tar archive and everything else fails.
3) The last - means to read the input data from stdin. You have to copy the backup and restore commands verbatim.
All commands are designed to be executed from a Linux host. I don't have access to a Windows or Mac OS box so I don't know if they will work there at all.
I am trying to mount a GCS bucket on AppEngine Flexible Environment app using gcsfuse.
My Dockerfiles includes the following:
# gscfuse setup
RUN echo "deb http://packages.cloud.google.com/apt cloud-sdk-jessie main" | tee /etc/apt/sources.list.d/google-cloud.sdk.list
RUN echo "deb http://packages.cloud.google.com/apt gcsfuse-jessie main" | tee /etc/apt/sources.list.d/gcsfuse.list
RUN wget -qO- https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
RUN apt-get update && apt-get install -y --no-install-recommends google-cloud-sdk gcsfuse strace
RUN gcsfuse --implicit-dirs my_bucket my_dir
I took most of this from here. It's pretty much just the standard way to install gcsfuse, plus --no-install-recommends.
If I start an app this way, it does not mount the drive. This was not too surprising to me, since it didn't seem like a supported feature of the flexible environment.
Here is the confusing part. If I run gcloud app instances ssh "<instance>", then run container_exec gaeapp /bin/bash, then gcsfuse my_bucket my_dir works fine.
However, if I run gcloud app instances ssh "<instance>" --container gaeapp, then gcsfuse my_bucket my_dir fails with this error:
fusermount: failed to open /dev/fuse: Operation not permitted
This is the same error I get if I run gcsfuse as a subprocess in my main.py.
Based on this unresolved thread, I ran strace -f and saw the exact same problem as that user did, an EPERM issue.
[pid 59] open("/dev/fuse", O_RDWR) = -1 EPERM (Operation not permitted)
Whichever way I log into the container (or if I run a subprocess from main.py), I am user root. If I run export then I do see different vars, so there is some difference in what's being run, but everything else looks the same to me.
Other suggestions I've seen include using the gcsfuse flags -o allow_other and -o allow_root. These did not work.
There may be a clue in the fact that if I try to run umount on a login that cannot run gcsfuse, it says "must be superuser to unmount", even though I am root.
It seems like there is probably some security setting that I do not understand. However, since I could in theory get main.py to trigger an external program to log in and run gcsfuse for me, it seems like there should be a way to get it to work without having to do that.
RUN commands are about creating a new layer for your dockerfile, so you're actually running that command during the image creation, which the Flex build system doesn't like.
I'm not sure why shelling out in the application didn't work, you could try 'sudo'ing it in the python subprocess, or possibly push it out of the application code by adding 'gcsfuse setup &&' to the ENTRYPOINT in the dockerfile.
I have edited the variable AllowOverride for one of my websites in sites-enabled directory. How do I reload the new configuration without restarting apache? Is it possible?
It should be possible using the command
sudo /etc/init.d/apache2 reload
Another way would be:
sudo service apache2 reload
Do
apachectl -k graceful
Check this link for more information :
http://www.electrictoolbox.com/article/apache/restart-apache/
If you are using Ubuntu server, you can use systemctl
systemctl reload apache2
Updated for Apache 2.4, for non-systemd (e.g., CentOS 6.x, Amazon Linux AMI) and for systemd (e.g., CentOS 7.x):
There are two ways of having the apache process reload the configuration, depending on what you want done with its current threads, either advise to exit when idle, or killing them directly.
Note that Apache recommends using apachectl -k as the command, and for systemd, the command is replaced by httpd -k
apachectl -k graceful or httpd -k graceful
Apache will advise its threads to exit when idle, and then apache reloads the configuration (it doesn't exit itself), this means statistics are not reset.
apachectl -k restart or httpd -k restart
This is similar to stop, in that the process kills off its threads, but then the process reloads the configuration file, rather than killing itself.
Source: https://httpd.apache.org/docs/2.4/stopping.html
Late answer here, but if you search /etc/init.d/apache2 for 'reload', you'll find something like this:
do_reload() {
if apache_conftest; then
if ! pidofproc -p $PIDFILE "$DAEMON" > /dev/null 2>&1 ; then
APACHE2_INIT_MESSAGE="Apache2 is not running"
return 2
fi
$APACHE2CTL graceful > /dev/null 2>&1
return $?
else
APACHE2_INIT_MESSAGE="The apache2$DIR_SUFFIX configtest failed. Not doing anything."
return 2
fi
}
Basically, what the answers that suggest using init.d, systemctl, etc are invoking is a thin wrapper that says:
check the apache config
if it's good, run apachectl graceful (swallowing the output, and forwarding the exit code)
This suggests that #Aruman's answer is also correct, provided you are confident there are no errors in your configuration or have already run apachctl configtest manually.
The apache documentation also supplies the same command for a graceful restart (apachectl -k graceful), and some more color on the behavior thereof.