04-14-2010
Quote:
Originally Posted by
garskoci
I prefer this method over something like live upgrade because I have control over what I'm doing.
I don't get that. You have control over what you are doing with live upgrade too. Your method is also inducing a service interruption time which might be unacceptable on a production system. Patching can take several hours to complete and live upgrade allows to do it while the system is running normally.
7 More Discussions You Might Find Interesting
1. Solaris
Hi there,
Apologies if this question has been asked and answered already but I've not been able to find the thread.
Question: Is it possible to apply the Solaris 10 Recommended Patch Cluster to a whole root (non-global) zone locally? I.E. apply the patch cluster from the non-global in... (3 Replies)
Discussion started by: nm146332
3 Replies
2. Shell Programming and Scripting
Dear experts,
I have an epoch time input file such as : -
1302451209564
1302483698948
1302485231072
1302490805383
1302519244700
1302492787481
1302505299145
1302506557022
1302532112140
1302501033105
1302511536485
1302512669550
I need the epoch time above to be converted into real... (4 Replies)
Discussion started by: aismann
4 Replies
3. Solaris
I'm trying to setup our jumpstart server to automatically apply the latest patch cluster during installs, but I'm running into an issue. Every time Jumpstart runs it has this error. Obviously it's processing the patch_order file, so I'm not sure what I'm missing.
... (0 Replies)
Discussion started by: christr
0 Replies
4. UNIX for Dummies Questions & Answers
what are the typical steps used by system adminstrators while applying an application patch upgrade (1 Reply)
Discussion started by: ramky79
1 Replies
5. Shell Programming and Scripting
# date +%s -d "Mon Feb 11 02:26:04"
1360567564
# perl -e 'print scalar localtime(1360567564), "\n";'
Mon Feb 11 02:26:04 2013
the epoch conversion is working fine. but one of my application needs 13 digit epoch time as input
1359453135154
rather than 10 digit epoch time 1360567564... (3 Replies)
Discussion started by: vivek d r
3 Replies
6. Ubuntu
I have applied a patch using this command:
patch -p1 < (file)
then I did git commit -a.
Now I want to recompile the kernel for making this patch live.
Should I use
make oldconfig
or
make localmodconfig
After that,
make -j$(grep -c "processor" /proc/cpuinfo)
sudo make... (1 Reply)
Discussion started by: BHASKAR JUPUDI
1 Replies
7. Debian
The version of Samba in our billing server is 4.1.17-Debian.
I have been reminded by our management to implement the patch for Samba on this server.
However, I am not sure how to implement the patch. I have browsed some websites for the correct patch to implement for Samba 4.1.17, and the patch... (11 Replies)
Discussion started by: anaigini45
11 Replies
LEARN ABOUT XFREE86
dh_systemd_start
DH_SYSTEMD_START(1) Debhelper DH_SYSTEMD_START(1)
NAME
dh_systemd_start - start/stop/restart systemd unit files
SYNOPSIS
dh_systemd_start [debhelperoptions] [--restart-after-upgrade] [--no-stop-on-upgrade] [unitfile...]
DESCRIPTION
dh_systemd_start is a debhelper program that is responsible for starting/stopping or restarting systemd unit files in case no corresponding
sysv init script is available.
As with dh_installinit, the unit file is stopped before upgrades and started afterwards (unless --restart-after-upgrade is specified, in
which case it will only be restarted after the upgrade). This logic is not used when there is a corresponding SysV init script because
invoke-rc.d performs the stop/start/restart in that case.
OPTIONS
--restart-after-upgrade
Do not stop the unit file until after the package upgrade has been completed. This is the default behaviour in compat 10.
In earlier compat levels the default was to stop the unit file in the prerm, and start it again in the postinst.
This can be useful for daemons that should not have a possibly long downtime during upgrade. But you should make sure that the daemon
will not get confused by the package being upgraded while it's running before using this option.
--no-restart-after-upgrade
Undo a previous --restart-after-upgrade (or the default of compat 10). If no other options are given, this will cause the service to
be stopped in the prerm script and started again in the postinst script.
-r, --no-stop-on-upgrade, --no-restart-on-upgrade
Do not stop service on upgrade.
--no-start
Do not start the unit file after upgrades and after initial installation (the latter is only relevant for services without a
corresponding init script).
NOTES
Note that this command is not idempotent. dh_prep(1) should be called between invocations of this command (with the same arguments).
Otherwise, it may cause multiple instances of the same text to be added to maintainer scripts.
Note that dh_systemd_start should be run after dh_installinit so that it can detect corresponding SysV init scripts. The default sequence
in dh does the right thing, this note is only relevant when you are calling dh_systemd_start manually.
SEE ALSO
debhelper(7)
AUTHORS
pkg-systemd-maintainers@lists.alioth.debian.org
11.1.6ubuntu2 2018-05-10 DH_SYSTEMD_START(1)