Sponsored Content
Operating Systems Solaris What kind of steps should be followed while applying patch in real time? Post 302412896 by jlliagre on Tuesday 13th of April 2010 11:43:01 PM
Old 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

Applying Recommended Patch Cluster to Whole Root Zone

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

Shell script to convert epoch time to real time

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

Jumpstart and Applying Recommended Patch Cluster

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

Typical steps to be followed while applying an application patch upgrade on linux

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

Converting real time to epoch time

# 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

Recompile the kernel after applying a patch in 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

Applying patch for Samba version 4.1.17

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
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)
All times are GMT -4. The time now is 06:11 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy