IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add a simple ExecStartPre command which reads the local node config,
and if a delay is set the helper sleeps that long then exists.
The systemd-unit approach was chosen as this ensures that we really
only delay when doing the startall on node boot. The pve-guests
service does not allows manual stops, starts or restarts, it can only
be pulled in by the multi-user.target
Mark this command with "-" to tell systemd that errors of it should
not cause an abort, it's a best-effort approach.
The journal from a 2 second delay would look like:
> Nov 19 13:13:48 dev6 systemd[1]: Starting PVE guests...
> Nov 19 13:13:48 dev6 pve-startall-delay[2318]: Delaying on-boot 'startall' command for 2 second(s).
> ...
> Nov 19 13:13:50 dev6 pve-guests[2339]: <root@pam> starting task UPID:dev6:00000924:00000529:5DD3DC7E:startall::root@pam:
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch builds the zsh tab completion scripts for the cli tools of
pve-manager.
In order for it to work, the latest version of pve-common and pve-docs
including the corresponding patches have to be installed on the build
system.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
this allows correct builds without pve-manager installed, with a clean
fall-back to the old behaviour in case pve-doc-generator is too old.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
In pve-common the following changes happened:
0adee98 ("cli_handler: pass common output options as separate parameter")
352b7a1 ("PVE::CLIFormatter - implement new output options")
We now get the format passed via an options hash in the
output function instead of seeing it as an api call
parameter.
Similarly, --quiet is now already handled there.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We have good command line completion and history with 'bash', so there is
no real need to duplicate this functionality.
Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
renew certificate if an acme config entry and a custom certificate
exists on the local node and the certificate expires soon.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Else systemd may start this to early on boot, before pve-cluster is
up and ready, if it missed and update because the node was offline.
This fails the services as it cannot do any IPC with pmxcfs
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
A email notification will be send for each job when the job fails.
This message will only send when an error occurs and the fail count is on 1.
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Acked-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
if we do not do this, passing arguments with spaces
(e.g., pvesh set YYY --param "one word")
leads to ssh calls like this:
ssh REMOTE pvesh set YYY --param one word
which cannot be parsed correctly
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Because the replication's purge_old_state() function now
fails if cfs_update() fails, and since it tries to access
the actual local pmxcfs it should never have been called by
tests anyway.
the name 'pve-manager' collides with our pve-manager package name,
which - from the user point of view - provides mainly the API and
WebUI.
An user could thus think that restarting 'pve-manager' would restart
the WebUIs server, which is relatable.
But, the pve-manager.service does not controls the WebUI or its
server but is responsible for starting all guest with 'onboot=1' in
their config on system boot and to stop all remaining running guests
on system shutdown.
Thus rename it to pve-guests and adapt its description. This may not
seem as ideal name at first glance, but its better than the current
option. Further it leads to log messages like:
> Starting PVE guests (Service providing start-on-boot and stop-all-on-shutdown)
> [...]
> Started PVE guests (Service providing start-on-boot and stop-all-on-shutdown)
> [...]
> Stopping PVE guests (Service providing start-on-boot and stop-all-on-shutdown)
which makes it clearer what happens, or what this service is for.
Alias the new service to the old pve-manager.service for legacy
reasons. While our services do not depend on it an user could have
made an own service which used pve-manager.service as synchronisation
point.
Linitian then complains about init.d/pve-manager not having a related
systemd service file. Instead of renmaning it just drop it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The API calls are not to chatty but may give helpfull hints about
what gets tried to be done.
This may help an Admin to figure out which guest delays his host
shutdown.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This services is responsible for bringing up 'onboot' marked guests
on host power-on and stop _all_ guests gracefully on host shutdown
(be it reboot, shutdow, halt, ..)
It's type is set to 'oneshot', which implies a TimeoutStartSec of
'infinity', by default. With Jessies Version of Systemd the
TimeoutStopSec defaulted to TimeoutStartSec, if not set – so also
'infinity'.
But, Debian Stretchs Version of Systemd makes TimeoutStopSec defaults
to 'DefaultTimeoutStopSec' if it was not set, which is by default 90
seconds – much less than infinity.
This may cause non-gracefull shutdowns of guests, as after the 90
seconds systemd sends a SIGKILL to the pvesh 'stopall' process.
This may end in a bad guest state then. But besides that it can also
lead to a hanging shutdown in some cirumstancesm, as some guest still
operated on storages, so systemd-shutdown - the binary which gets
exec'ed by systemd to become the new PID 1 cannot finish its
sync/umount/shutdown procedure. It has a watchdog armed on sync, if
that triggers you may even get a fully shut down system.
Else it can possibly hang forever, at least until the power plug gets
pulled or similar actions are taken.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
pvemailforward is a tiny oneliner, but for the sake of best
practices, let's use the build tools from the environment.
For example, with dpkg-buildpackage this will make us use
-D_FORTIFY_SOURCE=2 etc.
