Discuss

discuss@lists.centos.org

34753 discussions

upstart CentOS vs upstart Ubuntu is there any difference between them?
by reynierpm＠gmail.com 31 Mar '15

31 Mar '15

I'm moving some server configurations from Ubuntu Server 12.04 to CentOS 6.6. Now I'm working on `/etc/init` script that should be handled by `upstart` at both OS as far as I know. The files on both server are the same and I mean the same at content level and also at path level and permissions level, is the exactly copy from Ubuntu to CentOS. I'm having some issues with upstart at CentOS since scripts doesn't start and I can't find why (the cause). This is the output from `initctl list` at Ubuntu server: # Ubuntu 12.04 root@qa:/etc/init# initctl list // rest of processes goes here pdoneVendorBroker start/running, process 854 repToolBroker start/running, process 3705 emailBroker start/running, process 3738 cmeBroker start/running, process 3760 messageBroker start/running, process 3727 shareEventHandler start/running, process 3686 edetailBroker start/running, process 3749 pdoneLoginProctor start/running, process 3716 All the processes has been started at OS boot, that's fine. This is the output from CentOS server: # CentOS 6.6 root@staging:/etc/init# initctl list // rest of processes goes here pdoneVendorBroker stop/waiting repToolBroker stop/waiting emailBroker stop/waiting cmeBroker stop/waiting messageBroker stop/waiting shareEventHandler stop/waiting edetailBroker stop/waiting pdoneLoginProctor stop/waiting None processes has been started after OS boot, and that's wrong. Why? What I'm missing here? Can any give me some advice? At CentOS I've tried also to start the process manually by running this: initctl start messageBroker And this is the output at console: messageBroker start/running, process 3587 But if I run the command `initctl list` I didn't see the process started: initctl list rc stop/waiting tty (/dev/tty3) start/running, process 2565 tty (/dev/tty2) start/running, process 2562 tty (/dev/tty1) start/running, process 2558 tty (/dev/tty6) start/running, process 2577 tty (/dev/tty5) start/running, process 2574 tty (/dev/tty4) start/running, process 2571 plymouth-shutdown stop/waiting control-alt-delete stop/waiting debug stop/waiting rcS-emergency stop/waiting kexec-disable stop/waiting pdoneVendorBroker stop/waiting quit-plymouth stop/waiting rcS stop/waiting prefdm stop/waiting repToolBroker stop/waiting init-system-dbus stop/waiting emailBroker stop/waiting splash-manager stop/waiting cmeBroker stop/waiting start-ttys stop/waiting messageBroker stop/waiting shareEventHandler stop/waiting edetailBroker stop/waiting pdoneLoginProctor stop/waiting rcS-sulogin stop/waiting serial stop/waiting This is the content for the file `/ etc/init/messageBroker.conf`: description "messageBroker" start on runlevel [234] stop on runlevel [0156] respawn exec php /usr/local/bin/messageBroker/messageBroker.php post-start script PID=`status messageBroker| egrep -oi '([0-9]+)$' | head -n1` echo $PID > /var/run/messageBroker.pid end script post-stop script rm -f /var/run/messageBroker.pid end script Why it's not starting? What is wrong?

1 0

heavy IO load when working with sparse files (centos 6.4)
by Ron E 31 Mar '15

31 Mar '15

Dear List, We have noticed a variety of reproducible conditions working with sparse files on multiple servers under load with CentOS 6.4. The short story is that processes that read / write sparse files with large "holes" can generate an IO storm. Oddly, this only happens with holes and not with the sections of the files that contain data. We have seen extremely high IO load for example copying a 40 or 80gb sparse file that only has a few gigs of data in it. Attempts to lower the io priority and cpu priority of these processes do not make any measurable difference. (ionice, nice) This has been observed with processes such as: cp rsync sha1sum The server does have to be under some load to reproduce the necessary conditions. The cases we have seen involve servers running 10-30 guests under kvm. Load is in acceptable norms when the processes are run, such as load avg 5-15 on a 24 core (12 core with HT enabled) server. We also verify before starting such a process that the spindle with the file we're working on is not being unduly hammered by another process. These servers have one hardware raid controller each (Dell H700 controller with write cache enabled) and multiple raid arrays (separate sets of physical spindles). Interestingly, the IO storm is not limited to the array / spindles where the sparse file resides but affects all IO on that server. We have looked extensively and not found any account of a similar issue. We have seen this on configurations that are 'plain vanilla' enough to think that this is not something specific to our environment. Wondering if anyone else has seen this and if any suggestions on gathering more data / troubleshooting. We wonder if we've found either a raid controller driver issue, an OS issue or some other such thing. What seems to point in this direction is that even with ionice -c3 which should prevent the process from using IO unless the storage is idle, an io storm which appears to saturate the entire raid bus on a given server can occur. Thanks in advance.

3 3

NTLM Authentication ISA Server
by Tim 31 Mar '15

31 Mar '15

Hello list, how can I get CentOS 7 to authenticate against a Microsoft ISA server for package installations after the OS is installed. In Debian/Ubuntu apt.conf just needs to be edited and it works. How to do so in CentOS? Regards Tim

4 6

CentOS-announce Digest, Vol 121, Issue 13
by centos-announce-request＠centos.org 31 Mar '15

31 Mar '15

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CEBA-2015:0754 CentOS 6 cronie FASTTRACK BugFix Update (Johnny Hughes) 2. CEBA-2015:0755 CentOS 6 pinentry FASTTRACK BugFix Update (Johnny Hughes) 3. CESA-2015:0750 Moderate CentOS 6 postgresql Security Update (Johnny Hughes) 4. CEBA-2015:0756 CentOS 6 gnome-terminal BugFix Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Mon, 30 Mar 2015 13:24:20 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0754 CentOS 6 cronie FASTTRACK BugFix Update Message-ID: <20150330132420.GA60530(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0754 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0754.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 28de493fc3a314d52bb60c96688fd807c986e4a3885be4eb339c696229dd6b7c cronie-1.4.4-15.el6.i686.rpm ec22b667ff1f9f11ad54f9cb8eeaaf1fcbea2c4eb2a96f655bea877084b739ef cronie-anacron-1.4.4-15.el6.i686.rpm 5223d45f4a40ae9b521844f666504d55778e166f1c5cd8e8dc92bfd3ac22a2b6 cronie-noanacron-1.4.4-15.el6.i686.rpm x86_64: d2238fa4100380f7607393e48345614bc90e1385f1426dc1269c40b01f07b4bb cronie-1.4.4-15.el6.x86_64.rpm f3ea8f9f6fe548d64699592ccbe326ed474f7b1ae17df7a35b3010b419ed26d0 cronie-anacron-1.4.4-15.el6.x86_64.rpm 606d1a6d304f77eb0e05259fcc1e56391073469f4603040e32ba5637e17a34d6 cronie-noanacron-1.4.4-15.el6.x86_64.rpm Source: eba4bb44466ffc8965cd6f3e58e298ad522b0e95eca38cbc2f3b4521500b80ac cronie-1.4.4-15.el6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Mon, 30 Mar 2015 13:24:44 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0755 CentOS 6 pinentry FASTTRACK BugFix Update Message-ID: <20150330132444.GA60799(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0755 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0755.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: d1f4465b64e0161267195bb8fe53f9a8b5b1ee6e6159c3a6f983deae186bda0e pinentry-0.7.6-8.el6.i686.rpm ff437591b4f488bb9e7536e66495fe43ec35c58425b57cabc89e1d066e0365ec pinentry-gtk-0.7.6-8.el6.i686.rpm f72857f70505a1533aa91203b0d2e2b9de4d23b34ea170ea2202073b2ad2705e pinentry-qt-0.7.6-8.el6.i686.rpm 2b5d65c30499cc59b4eeb23b8f166c4511d0419250efa54414fc82c32c51e4c4 pinentry-qt4-0.7.6-8.el6.i686.rpm x86_64: 6c0de956f85b7f1f86b258462fb2546ee8f7f4f3b9e6eecd26a1ea80541964fe pinentry-0.7.6-8.el6.x86_64.rpm 335fec896578be4933278eb11d00a5613092f8e4a94f71339cd445b727bdc05e pinentry-gtk-0.7.6-8.el6.x86_64.rpm fb70a14ae035381aec2b738e8eb807bc61bdbe1dbda8fa5fb45cf003a8de8eb9 pinentry-qt-0.7.6-8.el6.x86_64.rpm e020b8d550bcdeac8b0842500592c857ad5fb4ca0b9938423162f420b39e5e02 pinentry-qt4-0.7.6-8.el6.x86_64.rpm Source: 8ef5e67049e28dfadf0bbcafe5ef34b2cc195f3f238c273ff9b3123d2d7f11f1 pinentry-0.7.6-8.el6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Mon, 30 Mar 2015 13:25:17 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2015:0750 Moderate CentOS 6 postgresql Security Update Message-ID: <20150330132516.GA61201(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2015:0750 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-0750.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 9b1c5e6fc09b4bd771526bba9121531dd56ae1066a7e976fcb0a9e59424ecf01 postgresql-8.4.20-2.el6_6.i686.rpm 2d6f25109301286cd1b4c70d76d8b55773aed22d102dee287604db820ef51f1c postgresql-contrib-8.4.20-2.el6_6.i686.rpm 20b37d3688e1231aadbbba02d9de9b1ef0ce14d29df11ddaba457b4e86c3c29f postgresql-devel-8.4.20-2.el6_6.i686.rpm 30e1bd187bf84d8972c738df54008b70bf6479ecbf9a062e0150dd34144a0819 postgresql-docs-8.4.20-2.el6_6.i686.rpm 54e959b271e297dceeaa579a1f7ae7681da67e967977be5bfc3ffd6d2f11066d postgresql-libs-8.4.20-2.el6_6.i686.rpm f90e6904076cf05ac3f078756b6d7d13c727396461ab109d1b2d561d9ff75cb6 postgresql-plperl-8.4.20-2.el6_6.i686.rpm 80bfe27e547b59982c5d25954b5ae85e4b1a6738e5768ae7451f7a772129c891 postgresql-plpython-8.4.20-2.el6_6.i686.rpm 4e89aae1a210bded523f0b0247396dcd1d00c4c0cb557fb89aa48e4c29c18ea8 postgresql-pltcl-8.4.20-2.el6_6.i686.rpm 8e7f2663b0a0eabab967dd85be0d4d8e4a6c2decb934e4e715898ba77ad1f964 postgresql-server-8.4.20-2.el6_6.i686.rpm 834720ab345e29b1492d95ba0ffcd74ef0eef4568a34141590332d057f70d053 postgresql-test-8.4.20-2.el6_6.i686.rpm x86_64: 9b1c5e6fc09b4bd771526bba9121531dd56ae1066a7e976fcb0a9e59424ecf01 postgresql-8.4.20-2.el6_6.i686.rpm ab2948563fa1d47ec9360d10e404f49ceb4f63e818fb949120ecf0c669fda391 postgresql-8.4.20-2.el6_6.x86_64.rpm 46c94eec4d5382afa1325726679e1947fe4b90aea36cd54667d1abdfcf237afd postgresql-contrib-8.4.20-2.el6_6.x86_64.rpm 20b37d3688e1231aadbbba02d9de9b1ef0ce14d29df11ddaba457b4e86c3c29f postgresql-devel-8.4.20-2.el6_6.i686.rpm ee3fdc90c751e7bff1c948e1b0c3a60c3088fbcd69f78f229b62c01a3417a254 postgresql-devel-8.4.20-2.el6_6.x86_64.rpm 33c0334ad155eff14642340d4ffe639321316112bb8335d3b6d73fa2debfdd5f postgresql-docs-8.4.20-2.el6_6.x86_64.rpm 54e959b271e297dceeaa579a1f7ae7681da67e967977be5bfc3ffd6d2f11066d postgresql-libs-8.4.20-2.el6_6.i686.rpm 7b470977301202de1b1fbb5b91e5fa6a49e22817e6d721128f245eb154562c0f postgresql-libs-8.4.20-2.el6_6.x86_64.rpm e74543976b939c8fb02645c5017724c950c2a0f5b055e92024c71aa974a995b7 postgresql-plperl-8.4.20-2.el6_6.x86_64.rpm 03293e559e9a5520dce545a0bdd59b16fce91a2bcc1d7d66a41dcab9b8c8baf4 postgresql-plpython-8.4.20-2.el6_6.x86_64.rpm 0a577fa35944d1edcda3575c0687c0e8502fa607ed22bdf2a125cb1eeff45edb postgresql-pltcl-8.4.20-2.el6_6.x86_64.rpm 4ed70e43633f1631dde37e269b44617fa4f5ccd5dba56d186a61ea2e365a719c postgresql-server-8.4.20-2.el6_6.x86_64.rpm 85b1c69ba73a7802aa51f844d53d3bc3ddb13c582e869260633f0c423a162dbb postgresql-test-8.4.20-2.el6_6.x86_64.rpm Source: cbef7bd40527f2b53850de5b2032aef78bc0bab3068e9ca231f483d302aa9a41 postgresql-8.4.20-2.el6_6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 4 Date: Mon, 30 Mar 2015 13:25:44 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2015:0756 CentOS 6 gnome-terminal BugFix Update Message-ID: <20150330132544.GA61389(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2015:0756 Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0756.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: f142f273b39b52330692113229fb1b2705bcb14cc7d3dca87c9af05b17c30547 gnome-terminal-2.31.3-11.el6_6.i686.rpm x86_64: d7d44f7bf07a6b695501abaf97615bff33d0a8b8624e507ee5de88b633f81e31 gnome-terminal-2.31.3-11.el6_6.x86_64.rpm Source: 091b062c38b298d7fe8bddff8e63d815e8aec3cf1a8ec8ffd8d237869c926fc4 gnome-terminal-2.31.3-11.el6_6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 121, Issue 13 ************************************************

1 0

Re: [CentOS] RAID not software raid
by Dan Purgert 31 Mar '15

31 Mar '15

On Mon, 30 Mar 2015 19:42:05 -0400, Stephen wrote: > > 16G/swap 500MB/boot 80G/home 50G/root > > 800G/sdb > > will not install Grub bootloader Fatal error Um, this is JBOD, and not RAID1. Raid1 would be 2x drives (sda & sdb) appearing as one single drive to the OS. Data is byte for byte mirrored between them.

1 0

race conditions in dbus-1.2
by Danny Smit 31 Mar '15

31 Mar '15

Hi everyone, I'm having some issue with a Qt application using D-Bus (Qt API) in a threaded appllication on CentOS 6. Searching for the cause has led me to the following issues in the dbus library: https://bugs.freedesktop.org/show_bug.cgi?id=857 https://bugs.freedesktop.org/show_bug.cgi?id=17754 It appears that there are threading issues with the dbus library version < 1.6. However there doesn't seem to be other version than 1.2 available for CentOS 6. Can someone advise what approach can be used to either work around or solve the issue? For instance, is it even possible to upgrade to a newer dbus version without side effects? Kind regards, Danny Smit

1 0

updating tzdata on CentOS 7
by Dulmandakh 31 Mar '15

31 Mar '15

Hello, Government of Mongolia decided to adopt DST from this 28th March 2015. It’s changes are submitted and accepted by IANA. It seems that update to tzdata (2015b) issued for CentOS 6, but not for CentOS 7. Could you please tell when an update for CentOS 7 will be issued? Thank you.

3 3

Centos 6.4 on Xserve, IPMI error
by Arno B 31 Mar '15

31 Mar '15

Hello! I'm trying to install Centos 6.4 64 bit on this Xserve: http://www.everymac.com/systems/apple/xserve/specs/xserve-intel-xeon-2.8-ei… I got a bootloader from: http://blog.christophersmart.com/2009/07/23/linux-on-an-apple-xserve-efi-on… as none of the official Centos releases (full, minimal, network 64 bit) boot on this machine. They all crash when loading the bootx64.conf. I have built a USB stick with a working bootx64.efi, grub.cfg, together with an initrd and a vmlinuz from the isolinux folder. These seem to get me into booting a kernel until something called IPMI is starting to throw errors at me: Console: switching to colour frame buffer device 128x48 fb0: VESA VGA frame buffer device ipmi message handler version 39.2 IPMI System Interface driver. ipmi_si 0000:09:00.4: enable device (0002 -> 0003) ipmi_si 0000:09:00.4: PCI INT C -> GSI 16 (level, low) -> IRQ 16 ipmi_si: Adding PCI-specified kcs state machine ipmi_si 0000:09:00.7: enable device (0000 -> 0003) ipmi_si 0000:09:00.7: PCI INT D -> GSI 17 (level, low) -> IRQ 17 ipmi_si: Adding PCI-specified bt state machine ipmi_si: Trying PCI-specified kcs state machine at mem address 0x90841000, slave address 0x0 irq 16 IRQ 16/ipmi_si: IRQF_DISABLED is not guaranteed on shared IRQs Using irq 16 ipmi: Found new BMC (man_id: 0x00003f, prod_id: 0x0003, dev_id: 0x20) IPMI kcs interface initialized ipmi_si: Trying PCI-specified kcs state machine at mem address 0x90840000, slave address 0x0 irq 17 Refined TSC clocksource calibration: 2792.999 MHz. Switching to clocksource tsc IPMI BT: timeout in XACTION [ B_BUSY ] 1 retries left IPMI BT: timeout in XACTION [ B_BUSY ] failed 2 retries, sending error response IPMI: BT reset (takes 5 secs) IPMI BT: timeout in XACTION [ B_BUSY H2B ] failed 2 retries, sending error response IPMI: BT reset (takes 5 secs) IPMI BT: timeout in XACTION [ B_BUSY H2B ] failed 2 retries, sending error response IPMI: BT reset (takes 5 secs) IPMI BT: timeout in XACTION [ B_BUSY H2B ] failed 2 retries, sending error response IPMI: BT reset (takes 5 secs) IPMI BT: timeout in XACTION [ B_BUSY H2B ] failed 2 retries, sending error response IPMI: BT reset (takes 5 secs) then the screen goes to black and the machine doesn't respond to anything anymore... Can anyone please help me with this? Maybe just point me in a direction where to find a solution? I've been googling for a few days now without much results... thanks in advance Arno Beekman

2 1

viewvc for EL7?
by Les Mikesell 30 Mar '15

30 Mar '15

Is there a reliable repo with viewvc for Centos7? Or some reason it isn't in EPEL? -- Les Mikesell lesmikesell(a)gmail.com

1 0

db2 is running out of shared memory
by Harold Pritchett 30 Mar '15

30 Mar '15

Db2 is running our of shared memory. The environment: Virtual computers running under VMware ESXi hypervisor version 5.5. Two different virtual machines, each running CentOS 5, db2 express C, and Apache/PHP and vmware tools. The machines each have 8 GB of memory, 4 processors, and a couple of hundred GB of disk space available. Everything is running on the 64 bit versions. The actual hardware for VMware is a dual processor machine with two Xeon E5410 processors, each with four cpu cores and 32 GB of ram. The difference in the two virtual machines is that one is running db2 version 9.7.1 and the other is running db2 version 10.5.5. The error occurs while restoring a backup taken on another server to the test server in question. Worse than that, it occurs when restoring a second database after the first restore works OK. The error message we are getting is this: On the 9.7 system: RESTORE DATABASE XYZZY USER db2inst9 using FROM '/db2home/restore1' INTO XYZZZ REPLACE EXISTING WITHOUT ROLLING FORWARD WITHOUT PROMPTING SQL1084C Shared memory segments cannot be allocated. SQLSTATE=57019 On the 10.5 system: RESTORE DATABASE XYZZY USER db2inst9 using FROM '/db2home/restore1' INTO XYZZZ REPLACE EXISTING WITHOUT ROLLING FORWARD WITHOUT PROMPTING SQL1084C The database manager failed to allocate shared memory because an`operating system kernel memory limit has been reached. SQLSTATE=57019 Everything I have read online says to increas the value of Shared Memory Size in the /etc/sysctl.conf file. However, on these systems it is already set to a value eight times larger than the actual memory size. The command "ipcs -l" give: [root@cowtest etc]# ipcs -l ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 67108864 max total shared memory (kbytes) = 17179869184 min seg size (bytes) = 1 ------ Semaphore Limits -------- max number of arrays = 1024 max semaphores per array = 250 max semaphores system wide = 256000 max ops per semop call = 32 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 2048 max size of message (bytes) = 65536 default max size of queue (bytes) = 65536 [root@cowtest etc]# the file /etc/sysctl.conf has the following in it # Controls the maximum size of a message, in bytes kernel.msgmax = 65536 # Controls the maximum shared segment size, in bytes kernel.shmmax = 68719476736 # Controls the maximum number of shared memory segments, in pages kernel.shmall = 4294967296 These numbers just don't make sense. kernel.shmmax is set to 64 GB, 8 times the actual memory of the machine. the value of "Total Max Shared Memory" from the ipcs command is 16 TB! I have other machine running on real hardware with only 6 GB of memory on which this works fine. What is so strange about the virtual machines? I'm posting this to both the db2 and CentOS mailing lists. Sorry for the duplication if you are subscribed to both. Harold Attached below is the complete output of the backup.restore job which ran on the db2 10.5 machine. The backup was taken on a db2 9.7 machine, hence the message about database upgraded to current db2 version. backup.restore 1.0.0 - submitted Mon Mar 30 05:45:01 EDT 2015 on cowtest waiting... 1 05:45:01 waiting... 2 05:46:01 waiting... 3 05:47:01 waiting... 4 05:48:01 waiting... 5 05:49:03 backup.restore - started Mon Mar 30 05:50:03 EDT 2015 on cowtest File to be restored is: /db2home/www/daily/ANIMALS.0.db2inst9.NODE0000.CATN0000.20150330030114.001.bz2 Testing file to be restored for integrity at Mon Mar 30 05:50:03 EDT 2015 unzipping backup file ------------ /db2home/db2inst9/archivelogs/animals ------------ total 0 ------------ /db2home/db2inst9/archivelogs/animals ------------ SQL1064N DB2STOP processing was successful. Waiting for 1 minute... SQL1063N DB2START processing was successful. ATTACH TO db2inst9 Instance Attachment Information Instance server = DB2/LINUXX8664 10.5.5 Authorization ID = DB2INST9 Local instance alias = DB2INST9 DEACTIVATE DATABASE ANIMALS DB20000I The DEACTIVATE DATABASE command completed successfully. RESTORE DATABASE ANIMALS USER db2inst9 using FROM '/db2home/restore1' REPLACE EXISTING WITHOUT ROLLING FORWARD WITHOUT PROMPTING SQL2555I The database was restored and then successfully upgraded to the current DB2 release where you issued the RESTORE DATABASE command. CONNECT to animals user db2inst9 using Database Connection Information Database server = DB2/LINUXX8664 10.5.5 SQL authorization ID = DB2INST9 Local database alias = ANIMALS SELECT count(bhid) from is3.dna 1 ----------- 220 1 record(s) selected. DETACH DB20000I The DETACH command completed successfully. DISCONNECT CURRENT DB20000I The SQL DISCONNECT command completed successfully. ACTIVATE DATABASE ANIMALS DB20000I The ACTIVATE DATABASE command completed successfully. TERMINATE DB20000I The TERMINATE command completed successfully. ATTACH TO db2inst9 Instance Attachment Information Instance server = DB2/LINUXX8664 10.5.5 Authorization ID = DB2INST9 Local instance alias = DB2INST9 RESTORE DATABASE ANIMALS USER db2inst9 using FROM '/db2home/restore1' INTO VERIFY REPLACE EXISTING WITHOUT ROLLING FORWARD WITHOUT PROMPTING SQL1084C The database manager failed to allocate shared memory because an operating system kernel memory limit has been reached. SQLSTATE=57019 connect to verify user db2inst9 using SQL1084C The database manager failed to allocate shared memory because an operating system kernel memory limit has been reached. SQLSTATE=57019 select count(bhid) from is3.dna SQL1024N A database connection does not exist. SQLSTATE=08003 DETACH DB20000I The DETACH command completed successfully. TERMINATE DB20000I The TERMINATE command completed successfully. system is cowtest SQL1064N DB2STOP processing was successful. SQL1063N DB2START processing was successful. DB20000I The ACTIVATE DATABASE command completed successfully. ------------ /db2home/db2inst9/archivelogs/20150330 ------------ total 0 ------------ /db2home/db2inst9/archivelogs/20150330 ------------ backup.complete file has already been removed... backup.restore - ended Mon Mar 30 07:44:52 EDT 2015 on cowtest

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss