My ntptime is showing error code 5 when the system starts. Restarting the ntpd through systemctl fixes this. Waiting a few minutes also seems to fix this. I have verified that ntpq shows that ntpd is talking to my intended server. This may be caused by another issue, but I think I'll take this time to ask a more general-purpose question.
Does anybody know which systemd dependencies are required for ntpd to work? I would love to see a minimum working example ntpd.service file from a system whose ntptime shows great success on system start.
Check your dependencies of a systemd unit with:
systemctl list-dependencies ntp
That command was found by reviewing man systemctl.
Related
I wrote a service that has to behave differently, depending on whether it is started after a boot or by the command "systemctl restart ...".
Can I find out that in the daemon itself? Or alternatively set an environment variable in the "daemon.service" file for the daemon?
At the moment I don't see how this can be decided e.g. from the environment.
Thanks in advance,
Poldi
Sorry,
stupid question. I just have to write a temporary file to a ram disk ;-)
In a virtual box I have a Debian that I sometimes want to run without X. So I edited /etc/grub.d/10_linux and added another menu item with a kernel option "nox" appended. Then I added a line to /lib/systemd/system/lightdm.service, Section [Unit]:
ConditionKernelCommandLine=!nox
However, when starting this, it hangs with the message:
A start job is running for Hold until boot process finishes up (56min / no limit)
Thank you, systemd for informing me about that. I wouldn't have noticed. Yet, I would like to know, which job it is that's hanging.
The system allows me to connect via SSH, but none of the systemctl or journalctl commands I tried did tell me the name of the service causing the problem. lightdm.service itself seems to be satisfied.
I known it's a but late, but I just found out that one can use:
systemctl list-jobs
to find out what units are waiting or running at any given moment.
By adding systemd.debug-shell=1 to the kernel command line, a root shell will be available on TTY9 (crlt+alt+F9) to run the command above.
I first tried "systemd-analyze", and that gave me the message about "systemctl list-jobs".
hope this helps someone with similar problems.
$ time sudo dbus-daemon --system
real 1m30.111s
user 0m0.017s
sys 0m0.003s
Barebone ArchLinux inside docker on ArchLinux.
D-Bus Message Bus Daemon 1.12.16
Tried dbus-x11 from AUR, same. Every time.
Edit/Details: the sudo invocation above takes 1:30 to execute, but the actual dbus-daemon process is spawned right away, and continues to run during and after the 1:30, successfully (i.e. it works). Reason I need dbus-daemon? for avahi-daemon (more specifically, to be able to run avahi-browse --all and discover stuff on my network).
Edit2: seems even though 'everything works' despite this slowness (avahi, network service discovery etc), the container becomes dead slow. Barely running sudo echo 'something' takes 25 seconds (a figure perhaps related to a timeout of 25000 inside /usr/share/dbus-1/system.conf). Just like an infection. For what it's worth, after reading more, seems the frustration of needing dbus is not restricted to the world of containerization - plenty of articles/communities like this and this.
I hit this issue with various Docker images, but not always. I digged deeper in this issue and found an interessting comment on the systemd repo.
The images I'm currently working on had systemd configured on passwd and group:
$ cat /etc/nsswitch.conf
passwd: sss files systemd
group: sss files systemd
Then I removed the systemd provider ($ sed -i 's/ systemd//g' /etc/nsswitch.conf) and the 90s hang was gone when starting with dbus-daemon --system --nofork. This was really a PITA to find out.
I could also verify that exactly this was the issue/difference for another Docker image I'm maintaining.
Using a free 'micro' instance from Amazon to fire up a quick demo of MarkLogic. The rpm installs fine with no errors.
Some information that may be helpful:
[user#aws ~]$ rpm -qa | grep release
redhat-release-server-6Server-6.4.0.4.el6.x86_64
[user#aws ~]$ rpm -qa | grep MarkLogic
MarkLogic-7.0-1.x86_64
Starting the MarkLogic server for the very first time shows this:
[user#aws ~]$ sudo /etc/init.d/MarkLogic start
Initialize Configuration
Region: us-west-2 ML_NAME:
Set configuration: MARKLOGIC_ZONE="us-west-2c"
Instance is not managed
Waiting for device mounted to come online : /dev/xvdj
And here it sits with no other messages anywhere including /var/opt/MarkLogic/Logs which doesn't exist yet.
Even though Micro instances aren't officially supported, you can usually start one up. But, reports are that you will be quickly wishing you didn't.
That said, see the precise instructions at http://developer.marklogic.com/products/aws and, in particular, a disk at mounting /dev/sdf ; the server init script will wait forever to come up if you don't do that.
If the above didn't help, I've dug into the RPM enough to discover some issues on AWS.
For one, they use some sysconfig scripts to detect if they're on AWS. If you're running MarkLogic 6, these sysconfigs have a hardcoded drive and will wait indefinitely since it probably won't exist. Yours is 7, and still has some issues on AWS. To bypass this, you can make a /usr/bin/is-ec2.sh that contains:
#!/bin/bash
exit 1
That will prevent it from doing any ec2 detection. More details can be found on my write-up at this github post
I have a PHP script that modifies my httpd.conf file, so I need to automatically reload it in Apache.
On Linux, there is graceful restart, but on Windows (I use the restart command) it terminates all the current connections. Is there a command as graceful restart on Windows? Is there a workaround on this?
Yes, you should use the -k switch.
httpd.exe -k restart or apache.exe -k restart
More info here has well. http://www.zrinity.com/developers/apache/usage.cfm
Edit:
It shouldn't that is the point of Graceful. Notice I used the -k. That is not the same as a normal restart. It let's the current sessions complete their task while the config is being reread, so that it will start taking new requests immediately.
From the documentation:
The USR1 or graceful signal causes the parent process to advise the children to exit after their current request (or to exit immediately if they're not serving anything). The parent re-reads its configuration files and re-opens its log files. As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.
http://httpd.apache.org/docs/2.2/stopping.html#graceful
It's doing what you are asking for.
Edit 2:
Adding this link and gave both possible versions because some people think you there is only one specific way to do something instead of search themselves.
http://httpd.apache.org/docs/2.4/platform/windows.html#wincons
I think I'm just going to delete this answer because either people can't read or if it doesn't work for someone it gets a DV. There are different windows versions made by different developers. If it doesn't work look for the answer from them. Even Linux has different commands depending on the distro. geez
In the newest Apache 2.4.20 VC10 the "httpd -k restart" command actually DOES do a graceful restart. It won't drop any connections, for example if somebody is downloading something from your server, it WILL NOT interrupt this process. One more proof is that "-k restart" will not reset your server statistics that mod_status provides, won't even alter the "Restart Time" value.
Although "httpd -k graceful" and "httpd -k graceful-stop" commands are available in Windows, but they will not work giving an error "couldn't make a socket".