I am running Open Source Chef 11 Server and a dozen or so Linux and SmartOs servers running chef-client. At one point I created a file on one of my linux servers with the filename of "down" in a specific directory and that prevented the chef-client from running, even after reboot. I have since deleted this file and I cannot remember which directory I had put that file in. I can no longer find any documentation that this existed or works. Did I imagine this?
I realize the point of Chef is to have chef-client running at all times but sometimes it is useful to disable the chef-client while experimenting with the server configuration.
I believe this "down" file might be related to runit.
I think I found it.
If I create the file in /etc/sv/chef-client
# touch /etc/sv/chef-client/down
then run
# sv status chef-client
I get back
down: chef-client: 85480s; run: log: (pid 8000) 93131s
If I remove the down file I get back
down: chef-client: 85539s, normally up; run: log: (pid 8000) 93190s
Related
I followed the instructions at this link which I found here on EE...http://nagios.sourceforge.net/docs/3_0/quickstart-fedora.html
Well after trying to stop nagios with command service nagios stop and after that to see its status with service nagios status the following message appears: "No lock file found in /usr/local/nagios/var/nagios.lock". How do I resolve it.
Thanks.
This is not a bug. "No lock file found in /usr/local/nagios/var/nagios.lock" means that it isn't running.
If you run an echo $? directly after service nagios status while it isn't running, you'll notice that the exit code is 3.
3 is the correct value return code for that status as documented in the Linux Standard Base.
Some Sources:
https://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html
http://ftp.novell.hu/pub/mirrors/ftp.novell.com/forge/library/SUSE%20Package%20Conventions/spc_init_scripts.html
Just run:
/usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
UPDATE:
The error: "No lock file found in /usr/local/nagios/var/nagios.lock" simply means that nagios is not running.
Running the command above simply starts the nagios daemon and points it to a specific config file. The advantage to running this command manually over systemd is that when you run "service nagios start" this typically calls the /etc/rc.d/init.d/nagios script which contains a line with parametrized environment variables:
$NagiosBin -d $NagiosCfgFile
Because every system is different, not specifying either the bin nor config directories could lead to nagios breaking (stopping) when it tries to start using the default installation directory paths
We have a FreeBSD 8 server that hasn't been restarted since it got booted. It has been restarted now and we're trying to reconnect the NFS mount to it.
$ sudo /etc/rc.d/nfsclient start
NFS access cache time=60
rpc.umntall: not found
The obvious reason for the error rpc.umntall: not found is because the program doesn't exist on the computer.
Is there any other way to mount to a NFS server that is connected to the network than using NFSClient. Or can I force the client to move past the part in the script that requires rpc.umntall?
I only ask because it was started before, and I'd be very surprised if we removed any programs from it.
rpc.umntall is installed as part of the base system, usually in /usr/sbin/.
If you take a look at the contents of /etc/rc.d/nfsclient, you'll find this:
unmount_all()
{
# If /var/db/mounttab exists, some nfs-server has not been
# successfully notified about a previous client shutdown.
# If there is no /var/db/mounttab, we do nothing.
if [ -f /var/db/mounttab ]; then
rpc.umntall -k
fi
}
A cheap work around would be to delete /var/db/mounttab.
However, if you want to fix the problem, you'll want to fix the missing rpc.umntall. Is it not in /usr/sbin/? If not, you could try to restore it from a published image, or you could attempt to build it from source.
If it's somewhere else on the computer, you could try to find it using find / | grep rcp.umntall.
If it exists in /usr/sbin, but isn't working, then that would likely mean that something is wrong with the PATH variable being used by your rc subsystem. You could double check that by hardcoding the path to rpc.umntall right in the /etc/rc.d/nfsclient script.
I am attempting to install REDHAWK v1.8.2 on a fresh install of CentOS 6.4 32 bit, but I am unable to get omniNames and omniEvents to start.
sudo /sbin/service omniEvents stop
Stopping CORBA event service: omniEvents
sudo /sbin/service omniNames stop
Stopping omniNames [ OK ]
sudo /sbin/service omniNames start
Starting omniNames [ OK ]
sudo /sbin/service omniEvents start
Starting CORBA event service on port 11169: omniEvents: [25848]: Warning - failed to resolve initial reference 'NameService'. Exception: TRANSIENT
omniEvents.
I tried to verify if omniNames was really running by calling the naming client, but got an error (see below), so it seems omniNames is not successfully starting.
nameclt list
Caught a TRANSIENT exception when trying to validate the type of the
NamingContext. Is the naming service running?
As part of the debugging process, I tried to kill the omniNames process and start it a different way (see below).
sudo killall omniNames
omniNames -start
Wed Nov 13 21:08:08 2013:
Starting omniNames for the first time.
Error: cannot create initial log file '/var/omninames/omninames-orion.log':
No such file or directory
You can set the environment variable OMNINAMES_LOGDIR to specify the
directory where the log files are kept.
I'm not sure why omniNames can't create the log file, because I verified that /var/omninames folder actually exists and even starting omniNames as root yields the same error. Regardless, I set the log directory to my desktop to circumvent the error (see below).
export OMNINAMES_LOGDIR=/home/$USER/Desktop/logs
mkdir -p /home/$USER/Desktop/logs
omniNames -start
Wed Nov 13 21:09:17 2013:
Starting omniNames for the first time.
Wrote initial log file.
Read log file successfully.
Root context is IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000001000000000000005c000000010102000a00000031302e322e382e333500f90a0b0000004e616d6553657276696365000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100
Checkpointing Phase 1: Prepare.
Checkpointing Phase 2: Commit.
Checkpointing completed.
Even though it looks like omniNames successfully started, when I open another terminal window and call the naming client, I get the same error as before (see below).
nameclt list
Caught a TRANSIENT exception when trying to validate the type of the
NamingContext. Is the naming service running?
The only modification I made in the /etc/omniORB.cfg file is to add the lines for InitRef (see below).
InitRef = NameService=corbaname::localhost
InitRef = EventService=corbaloc::localhost:1169/omniEvents
Also, I am not connected to the internet so my version of CentOS has not been updated from the base version, except for the boost libraries as recommended in Appendix J of the manual (http://sourceforge.net/projects/redhawksdr/files/redhawk-doc/1.9.0/REDHAWK_Manual_v1.9.0.pdf/download).
Looks like the issue is in your configuration. You've got the wrong port in your configuration file. It should be port 11169 however you've listed port 1169.
See: http://redhawksdr.github.io/Documentation/mainch2.html#x4-120002.6 for details.
A few other observations and tricks regarding omniOrb in case this was not the issue.
Sometimes omninames/omnievents can get into a bad state. The fix is to delete the log files created by omniNames and omniEvents and restart the services. They are located:
/var/lib/omniEvents/*
/var/omniNames/*
You'll need to be root to delete those files. I always forget where they are located and often do a "locate omni | grep -i log" to remind myself but you must do this as root since they are not visible to standard users.
While it should not matter, I've personally found that using 127.0.0.1 is more reliable than localhost. For some reason, using localhost within a VM in the configuration file has caused me problems in the past. Consider using 127.0.0.1 instead of localhost. This is what the current version of the Redhawk Manual recommends as well.
You mentioned you are using Redhawk v1.8.2. As an FYI, the latest REDHAWK version in the 1.8 series is currently v1.8.5 and 1.9.0 was also recently released.
Hopefully this gets you up and running!
In the Redhawk IDE, when I try to connect I get the following error.
Connecting Domain, has encounterd a problem
Details are
Failed to connect
org.omg.CosNaming.NameingContextPackage.NotFound: IDL: omg.org/CosNaming/NamingContext NotFound:1.0
It does not appear that a DomainManager is getting started at all, I have the
OmniEvents and OmniOrb running and the /etc/Omni config file set up as described in the
documenation.
I have tried to delete and redo the DomanManger ConnnectionSettings with REDHAWAK_DEV
corbaname::localhost:2809 but nothing helps.
It appears that omniNames is in a bad state, which should be resolvable through a hard reset of the service. To do a hard reset of omniNames, you will need to stop the omniNames service, delete the files in /var/log/omniORB, and then restart the omniNames service:
# /sbin/service omniNames stop
# rm -f /var/log/omniORB/*
# /sbin/service omniNames start
Note: do not delete the omniORB directory: just delete its contents.
More details on this are in the 1.9 user manual (which may not have been available at the time of your post) in "Appendix H: Resolving omniNames/omniEvents Failures".
I have installed successfully the roar-penguin pppoe-server and trying to use it without success, what I don't understand is that, when I put in my /etc/ppp/pppoe-server-options
debug
logfile /var/log/pppoe-server-log
But that file is not created and I don't understand what happens. It is really hard for me find a solution. Do you know how can I enable the debugging ?
My problem is that I catch every time (Wireshark sniffing) the
RP-PPPoE: Child pppd process terminated
In the PADT message, any help ?
Thanks in advance.
From your question not being formatted, verify that debug and logfile in /var/log/pppoe-server-log are on separate lines in your configuration file. Also, ensure that you've restarted the service to utilize the new configuration. If the service is not running as root, be sure that the user it runs as has ownership over the logfile to write to it. If it is running as root, ensure the file exists and that it's writable.
If it doesn't exist, just run:
# touch /var/log/pppoe-server-log
# chmod 0774 /var/log/pppoe-server-log
I would think this should be done automatically, but you may as well do so just to ensure it's created properly and you can verify ownership/permissions as needed.