[Linux-HA] crm configure show to a pipe
Hi Kristoffer, all, running 'crm configure show > file' appends non-printable chars at the end (at least if op_defaults is used): ... property cib-bootstrap-options: \ dc-version=1.1.12-c191bf3 \ cluster-infrastructure=corosync \ cluster-recheck-interval=10m \ stonith-enabled=false \ no-quorum-policy=freeze \ last-lrm-refresh=1415955398 \ maintenance-mode=false \ stop-all-resources=false \ stop-orphan-resources=true \ have-watchdog=false rsc_defaults rsc_options: \ allow-migrate=false \ failure-timeout=10m \ migration-threshold=INFINITY \ multiple-active=stop_start \ priority=0 op_defaults op-options: \ record-pending=true.[?1034h Best, Vladislav ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
Re: [Linux-HA] time_longclock illumos
> On 17 Nov 2014, at 5:17 am, Randy S wrote: > > Hi all, > > new user here. > We have been testing an older version of the heartbeat / pacemaker > combination compiled for illumos (an opensolaris follow-up). > Versions: > Heartbeat-3-0-STABLE-3.0.5 > Pacemaker-1-0-Pacemaker-1.0.11 The 1.0.x series is now long departed. Best to look into a recent 1.1.x build > > It all works ok while testing (several months now) but I have noticed that > every so often (and sometimes quite frequently) I see the following console > message appear: > > crmd: [ID 996084 daemon.crit] [12637]: CRIT: time_longclock: old value was > 298671305, new value is 298671304, diff is 1, callcount 141814 > > Now from what I have been able to find about this, is that this type of > occurence should have been fixed in heartbeat post 2.1.4 versions. At that > time this occurence could make a cluster start behaving irratically. > We have two test implementions of a cluster, 1 in vmware and 1 on standard > hardware. All just for testing. > We have made sure that timesync is done via ntp with the internet. The > hardware implementation doesn't show this message as many times as the vmware > implementation, but still it appears (sometimes about three times per 24 > hours). > > We haven't had any strange behaviour yet in the cluster, but my questions > about this are as follows: > > should we worry about this 'time_longclock' crit error eventhough it should > have been fixed in version post HA 3? > > Is there something (simple) that can be done to prevent this type of error, > or should we expect normal cluster behaviour since ntp is used. > > The above message should make clear that I'm not a programmer, nor am I a > heartbeat specialist ;-) > > Regards, > > S. > > > > ___ > Linux-HA mailing list > Linux-HA@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
[Linux-HA] time_longclock illumos
Hi all, new user here. We have been testing an older version of the heartbeat / pacemaker combination compiled for illumos (an opensolaris follow-up). Versions: Heartbeat-3-0-STABLE-3.0.5 Pacemaker-1-0-Pacemaker-1.0.11 It all works ok while testing (several months now) but I have noticed that every so often (and sometimes quite frequently) I see the following console message appear: crmd: [ID 996084 daemon.crit] [12637]: CRIT: time_longclock: old value was 298671305, new value is 298671304, diff is 1, callcount 141814 Now from what I have been able to find about this, is that this type of occurence should have been fixed in heartbeat post 2.1.4 versions. At that time this occurence could make a cluster start behaving irratically. We have two test implementions of a cluster, 1 in vmware and 1 on standard hardware. All just for testing. We have made sure that timesync is done via ntp with the internet. The hardware implementation doesn't show this message as many times as the vmware implementation, but still it appears (sometimes about three times per 24 hours). We haven't had any strange behaviour yet in the cluster, but my questions about this are as follows: should we worry about this 'time_longclock' crit error eventhough it should have been fixed in version post HA 3? Is there something (simple) that can be done to prevent this type of error, or should we expect normal cluster behaviour since ntp is used. The above message should make clear that I'm not a programmer, nor am I a heartbeat specialist ;-) Regards, S. ___ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
