is there a way how to ensure the reboot of the linux machine after puppet run?
Can take advantage of reboot or shutdown -r commands and to typical patern resurce - subscribe pattern but that doesn't ensure that exec shutdown resource will be synchronized as a last one.
Could someone please advice the best approach?
Related
For a while, I was using virt-install to install an OS on libvirt VMs. I learned that the OS has an autoinstaller feature that requires the use of a second CD-ROM (to feed information about the desired configuration to the installer), but I found that virt-install unfortunately ignores all but one --cdrom argument. The alternative that I came up with is to output the VM configuration virt-install would use with just one CD-ROM to a file using the --print-xml argument, edit that file to add the second CD-ROM, and then use virsh create <xml config file>.
When I was using virt-install before, the VM rebooted itself at the end of installation and virt-install would notice and shut down ("destroy") the VM instead of allowing it to reboot, leaving me with a nice clean installed disk image. However, now when the VM reboots after completing installation, it actually boots up again instead of shutting down cleanly, so I can't programmatically tell when the installation has completed. After the reboot it looks like the same qemu-system-x86_64 process is being used, so I also can't use it to tell when the installation has completed.
How can I force libvirt to shut down ("destroy") the VM instead of rebooting the way virt-install did? Alternatively, is there some other indicator I can use to tell that a VM reboot has occurred?
Although there doesn't seem to be a way to automatically destroy a libvirt VM on reboot through a special incantation of virsh create or by changing options in the domain XML file, I stumbled across the very useful virsh event command:
$ virsh help event
NAME
event - (null)
SYNOPSIS
event [<domain>] [<event>] [--all] [--loop] [--timeout <number>] [--list]
DESCRIPTION
List event types, or wait for domain events to occur
OPTIONS
[--domain] <string> filter by domain name, id, or uuid
[--event] <string> which event type to wait for
--all wait for all events instead of just one type
--loop loop until timeout or interrupt, rather than one-shot
--timeout <number> timeout seconds
--list list valid event types
The command blocks until an event of the specified type occurs for the specified domain. This allowed me to achieve my goal of emulating the behavior in virt-install by doing:
$ virsh event domain1 --event restart
event 'reboot' for domain -
events received: 1
$ virsh destroy domain1
And it even gives me a built-in timeout mechanism!
I have a Debian VM with puppet client installed.
All is well when I manually run:
puppet agent
after I run it, I can see using "service puppet status" that the process is running OK.
I want this process (starting the puppet agent) to happen automatically on system boot.
I followed the instructions of changing /etc/init.d/puppet so that it starts
START=yes
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/puppet
DAEMON_OPTS=""
NAME=agent
DESC="puppet agent"
PIDFILE="/var/run/puppet/${NAME}.pid"
BUT - when I boot the system, this service does not start !
What am I doing wrong ?
I
You need to set START=yes in /etc/default/puppet instead of right in the initscript.
As an aside, this question would be more suitable on ServerFault.
I have a script (twoRules.sh) which add rules to ovs plugin bridge.
The rules gets deleted when someone does service neutron-plugin-openvswitch-agent restart or reboots the system. So where should I put my scripts so that after the restart of neutron-plugin-openvswitch-agent the (twoRules.sh) scripts get executed successfully and rules remain added.
I tried putting it in /etc/init.d/neutron-plugin-openvswitch-agent file as other people suggested but this file is only called on /etc/init.d/neutron-plugin-openvswitch-agent restart and not on service neutron-plugin-openvswitch-agent restart.
You have to convert the script to a a SysV-style init script. There are many documents out there explaining about this.
http://www.debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian
http://www.cyberciti.biz/tips/how-to-controlling-access-to-linux-services.html
https://wiki.debian.org/Daemon
This way you can configure the script to be executed after certain services start or stop or when runlevel changes.
We are finishing development of a project, the client is already using it but occasionally some errors occur - crashing the server.
I know I could register a service as 'upstart' script on linux, in order to have my node service restart when it crashes.
But our server is running other stuff, so we can't restart it.
Well, actually, while writing, I realize I have two questions then:
Will 'upstart' work without having to reboot? Something is just whispering yes to me :)
If not, what other option would I have to 'respawn' my node server when it crashes?
Yes, upstart will restart your process without a reboot.
Also, you should look into forever.
PM2 is a Production process manager for Node.js app.
If your focus for automatic restart is an always running application, I suggest to use a process manager. Process manager, in general, handles the node process(es if cluster enabled), and is responsible for the process/es execution. PM leans on the operative system: your node app and the OS are not so strinctly chained because the pm is in the middle.Final trick: put the process manager on upstart. Here is a complete performance improvement path to follow.
Using a shared server and not having root privileges, I can't download or install any of the previously mentioned libraries. What I am able to do is use a simple infinite bash loop to solve my issue. First, I created the file ./startup.sh in the base directory ($ vim startup.sh):
#!/bin/bash
while:
do
node ./dist/sophisticatedPrimate/server/main.js
done
Then I run it with:
$ bash startup.sh
and it works fine. There is a downside to this, which is that is doesn't have a graceful way to end the loop (at least not once I exit the server). What I ended up doing is simply finding the process with:
$ ps aux | grep startup.sh
Then killing it with
$ kill <process id>
example
$ kill 555555
Since I install pending updates for my Ubuntu server as soon as possible, I have to restart my linux server quite often. I'm running an webapp on that server and would like to warn my users about the pending restart. Right now, I do this manually, adding an announcement before the restart, give them some time to finish their work, restart and remove the announcement.
I hope, shutdown -r +60 writes an file with all the information about the restart, which I can check on every access. Is there such a file? Would prefer a file in a virtual file system like /proc for performance reasons...
I'm running Ubuntu 10.04.2 LTS
If you are using systemd, the following command shows the scheduled shutdown info.
cat /run/systemd/shutdown/scheduled
Example of output:
USEC=1636410600000000
WARN_WALL=1
MODE=reboot
As remarked in a comment by #Björn, USEC is the timestamp in micro seconds.
You can convert it to a human friendly format dropping the last 6 figures and using date like this:
$ date -d #1636410600
Mon Nov 8 23:30:00 CET 2021
The easiest solution I can envisage means writing a script to wrap the shutdown command, and in that script create a file that your web application can check for.
As far as I know, shutdown doesn't write a file to the underlying files system, although it does trigger broadcast messages warning of the shutdown, which I suppose you could write a program to intercept .. but the above solution seems the easiest.
Script example:
shutdown.bsh
touch /somefolder/somefile
shutdown -r $1
then check for 'somefile' in your web app.
You'd need to add a startup link that erased the 'somefile' otherwise it would still be there when the system comes up and the web app would always be telling your users it was about to shut down.
You can simply check for running shutdown process:
if ps -C shutdown > /dev/null; then
echo "Shutdown is pending"
else
echo "Shutdown is not scheduled"
fi
For newer linux distributions versions you might need to do:
busctl get-property org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager ScheduledShutdown
The method of how shutdown works has changed
Tried on:
- Debian Stretch 9.6
- Ubuntu 18.04.1 LTS
References
Check if shutdown schedule is active and when it is
The shutdown program on a modern systemd-based Linux system
You could write a daemon that does the announcement when it catches the SIGINT / SIGQUIT signal.