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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The ceph-disk service seems to have been removed with octopus (v15) and
we did not yet have them for ceph-volume which could lead to some
startup issues in cases where the pve-cluster service did not start fast
enough.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
see https://github.com/systemd/systemd/issues/5595
Has also the side effect of spreading out the updates for our most
used product over a longer time span, reducing load on the CDN.
Note, this is now the same timer setting as PBS used from the start.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This way, a running backup cannot prevent pve-guests from starting a
virtual guest which was marked with 'onboot'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
utilize PVE::Daemons 'hup' functionality to reload gracefully.
Leaves the children running (if any) and give them to the new instance
via ENV variables. After loading, check if they are still around
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The whole thing is already prepared for this, the systemd timer was
just a fixed periodic timer with a frequency of one minute. And we
just introduced it as the assumption was made that less memory usage
would be generated with this approach, AFAIK.
But logging 4+ lines just about that the timer was started, even if
it does nothing, and that 24/7 is not to cheap and a bit annoying.
So in a first step add a simple daemon, which forks of a child for
running jobs once a minute.
This could be made still a bit more intelligent, i.e., look if we
have jobs tor run before forking - as forking is not the cheapest
syscall. Further, we could adapt the sleep interval to the next time
we actually need to run a job (and sending a SIGUSR to the daemon if
a job interval changes such, that this interval got narrower)
We try to sync running on minute-change boundaries at start, this
emulates systemd.timer behaviour, we had until now. Also user can
configure jobs on minute precision, so they probably expect that
those also start really close to a minute change event.
Could be adapted to resync during running, to factor in time drift.
But, as long as enough cpu cycles are available we run in correct
monotonic intervalls, so this isn't a must, IMO.
Another improvement could be locking a bit more fine grained, i.e.
not on a per-all-local-job-runs basis, but per-job (per-guest?)
basis, which would improve temporary starvement of small
high-periodic jobs through big, less peridoci jobs.
We argued that it's the user fault if such situations arise, but they
can evolve over time without noticing, especially in compolexer
setups.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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>
in nautilus there is no ceph-disk anymore and osd activation
does not use udev anymore so this service is not needed anymore
remove it and do not copy it when installing a new ceph cluster
in pve-storage.target we replace ceph.service with ceph.target
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This way they can cleanly exit (with a SIGTERM or systemctl stop) but
will get restarted if killed or they abort, but only for
StartLimitIntervalSec= time period with a total maximal count of
StartLimitBurst= retries.
See `man systemd.unit` for details, default are 10s total
restart retry period with at max 5 total retry counts, after that the
unit will placed in the failure state. So this is a best effort try
with no real downside.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
as already announced over two months ago[0], remove the unofficial
SheepDog plugin now completely. Besides that it was never fully
supported in Proxmox VE one of its main developer and ex-maintainer
declared it as abandoned[1], and thus just let's remove it, git
allows to resurrect it any time if a wonder happens anyway.
[0]: https://pve.proxmox.com/pipermail/pve-user/2019-March/170497.html
[1]: http://lists.wpkg.org/pipermail/sheepdog/2019-March/068449.html
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
