Please check the attached screenshot, puppetrun is called repeatedly for every 3 min and its keep on running certain critical services repeatedly. I want puppetrun to be called on demand. not an automated call like this.
In puppet.conf file, Do I have to enable any parameters to stop this repeated puppetrun invoke ? or I have to make any changes in foreman ?
or is it the puppetmaster triggering this call on all clients ?
Do you mean every 30 minutes? The screenshot shows only three runs, possibly within a two hour period.
Usually the Puppet agent is running as a service which can be stopped and disabled - commands vary depending on your OS. For a systemd-based OS:
systemctl stop puppet
systemctl disable puppet
service puppet stop should at least stop it on others, check your OS docs for commands to disable the service at startup.
However when using Puppet, it should be perfectly safe for the agent to run continually and ensure state. The catalog shouldn't be affecting a service every time it runs, it suggests an error.
Related
I am trying to allow a application to update itself by calling an RPM packet manager (right now DNF) to install an RPM containing an update. The problem is that when the packet manager uninstalls the application, the service is stopped and the packet manager is killed before it can install the new RPM.
Is there any way to detach the packet manager process so it can finish the update?
It's not clear how much control you have over how the update is run.
One possible option is to put a check for updates, and the update itself, in a program that is run by a cron job. It's common for RPMs to install cron jobs, and the cron job won't be stopped if the service associated with the application is stopped.
If the update must be started directly by the service, and you can control how the update is invoked, then you could use the at command to run it. See Run command 'at' 5 seconds from now for examples of using at. The update would be run by a separate service, so it wouldn't be stopped when your service is stopped. However, this requires at to be installed and the atd daemon to be running.
I want to install one chef client on a linux server to manage the server by executing shell command. While there is a reboot command in one of the recipes in the run list, and the rest recipes don't continue to execute after the server reboot. As I haven't found a way to solve it, I wonder if I can install two chef clients on a Linux server and execute different recipes so that the rest recipes can continue to execute after the server reboot. Anyone can help? Thanks.
Putting two clients on a single device, or two Configuration Management tools on the same box in general, is a Bad Idea. Even if you could do it the cognitive load increase from determining when to update what where going forward is going to open you up to mistakes.
The proper approach is to put restart flags in your recipes; before you call the restart resource you set a flag (which can be a files contents or even existence, an environment variable, or any number of other persistent data objects) to indicate that a restart was performed. If its to be periodic you can instead look at something like the last time a file was accessed with its atime property. Then you do logic around your steps that require a reboot, guarding against a reboot if the flag no-restart flag is set or triggering it if you have a restart flag set, your choice. That way you'll have a chef converge with a restart that skips part of your runlist, then later another run that skips the unnecessary restart process.
Another good option is to just pay more attention to how you have your resources ordered. If the restart is in your last runlist item and is notified with the :delayed timing then it will be the last run resource, meaning the rest of your recipes would have already converged. If you need a complete converge every time then that is the option you should embrace.
Option 1 is a Ruby-centric solution and will require you to embrace dev work. Option 2 is more pure Chef with some Ruby sprinkled in and you can read up on notifying resources in the docs here: https://docs.chef.io/resource_common.html#notifications
There is an option 3 where you change the runlist during the chef run, which you could use to remove the recipes that require the reboot, but I think you'd benefit more from option 1 or 2.
I'll keep it simple.
I have multiple instances of the same micro service (using dockers) and this micro service also responsible of syncing a cache.
Every X time it pulls data from some repository and stores it in cache.
The problem is that i need only 1 instance of this micro-service to do this job, and if it fails, i need another one to take it place.
Any suggestions how to do it simple?
Btw, is there an option to tag some micro-service docker instance and make him do some extra work?
Thanks!
The responsibility of restarting a failed service or scaling up/down is that of an orchestrator. For example, in my latest project, I used Docker Swarm.
Currently, Docker's restart policies are:
no: Do not automatically restart the container when it exits. This is the default.
on-failure[:max-retries]: Restart only if the container exits with a non-zero exit status. Optionally, limit the number of restart retries the Docker daemon attempts.
unless-stopped: Always restart the container regardless of the exit status. When you specify always, the Docker daemon will try to restart the container indefinitely. The container will also always start on daemon startup, regardless of the current state of the container.
always: Always restart the container regardless of the exit status, but do not start it on daemon startup if the container has been put to a stopped state before.
I am using "Debian 3.10.5-1~bpo70+1". Generally after a shutdown / restart, CUPS service is not automatically started.
1) What could be the reasons other then if not specifically implemented by the Sys-Admins?
2) Is there any security issue if I add a group with privilege to start the CUPS service and assign the group to each user.
Thanks in advance. Let me know if any further details needed.
Possible causes:
The startup daemon which is supposed to be run automatically at startup is not being executed
The daemon is being executed, but something has changed and it bombs out before completing.
Immediately after startup, look at the files in /var/log that are newer than the time of startup (each file is written FIFO).
I have a Nagios box installed and it monitors 342 services at the moment.
One of those service checks is for System Up Time. When 30 days lapses, I have it configured to send CRITICAL alarms....Time to REBOOT!
I click on my services link and check each one individually to see what the system up time is; on each Host.
Does anyone think there is a script I could run in a terminal to check only SYSTEM UP TIME for all host's? That way I can get a report of them everyday without have to go line by line to check them?
Just curious.
Thanks for looking everyone!
You can put python or bash script on each host that says if the machine more 30 days up -> reboot.
You can write some script on your local macine that will access each host once per day and will check uptime of each host and make reboot if needed, but at this way you will need to create ssh accees to each host.