Activity for elunlen
-
elunlen committed [401989]
ntfs doc: Clearify connection between CCB operations and notifications
-
log doc: Add information about new attribute logFileIoTimeout [#578]
-
logsv doc: Document implementation of day name/no tokens [#586]
-
log doc: Description of new features added in OSAF 4.7 [#1468]
-
log: Update document with version 5.2 enhancements [#2200]
-
smf: Expalain how osafAmfRestrictAutoRepairEnable setting in AMF affects SMF
-
SMF: Improve/correct ccb handler rules for recovery
-
smf: Do CCB Recovery in ccb handler insted of inline [#3071]
-
SMF: Improve/correct ccb handler rules for recovery
-
SMF: Move the generic IMM ccb handler in SMF to IMM tools as a library
-
This fix will be implemented. SInce immdump will be changed to set <value xsi:nil=""></value> instead of <value></value> and this changed is somewhat NBC a new option will be added to immdump. When this option is set this new more correct behaviour will be used.
-
Ticket [#2985] is probaly invalid so this ticket should also be set invalid. See comment in ticket #2985
-
The ticket should be set invalid. To me it seems as if the use case described in the ticket is not really valid even if the IMM behavior is a bit inconsistent (value=<empty> is replaced by default at restart but other values are not). If I have understood it correctly you say that an attribute where an empty value has a significant meaning (from ticket: MaxAge=<empty> means that a password never expires). This is in itself not an invalid use case but there is already a way to avoid this behavior...
-
Note that security must be handled if this attribute is made writable. If the path can be changed it must be ensured it cannot be given a value outside of the allowed directory structure etc. (other security issues?). Verification must be implemented This is a relative path and the root path is given in the log configuration object (that has checks) so there should be no problem. But check to be sure. Note how the root path is verified. Is not allowed to contain any ../ etc.
-
Note that security must be handled if this attribute is made writable. If the path can be changed it must be ensured it cannot be given a value outside of the allowed directory structure etc. (other security issues?) This is a relative path and the root path is given in the log configuration object (that has checks) so there should be no problem. But check to be sure.
-
ntf: Alarm notifications queued for logging may not be logged
-
After some investigations it seems as if it should not be possible to use "boolean string values" making this ticket invalid and this fix will actually be NBC
-
smf: Smfnd does not protect global variables used in more than one thread
-
smf: Validation error for rollback CCB and a related core dump
-
commit e179caed7df7f41aefd31c08065af854dd9e6cd4 Author: Lennart Lund lennart.lund@ericsson.com Date: Thu Jun 7 15:45:18 2018 +0200 smf: Validation error for rollback CCB and a related core dump [#2858] SMF imm operation lists may contain duplicate create operations. Fix, rollback data shall not be stored for duplicate operations and duplicate operations shall not be added to the CCB. Fix, crash in SmfUtil::doImmoperation if the CCB fails
-
smf: Validation error for rollback CCB and a related core dump [#2858]
-
smf: Validation error for rollback CCB and a related core dump [#2858]
-
smf: Validation error for rollback CCB and a related core dump
-
smf: Validation error for rollback CCB and a related core dump [#2858]
-
The lists of IMM operations that are created in many places may contain object create operations for objects that already exists in the IMM model. The lists may also contain more than one create operation for the same object. If a create operation for any of the duplicates is added to the CCB, ERR_EXSIST will be returned. To avoid this it must be checked for each create operation if the IMM model already contains the object and also that the same object create is not added twice to the CCB. Also...
-
smf: Validation error for rollback CCB and a related core dump
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Incorrect logging may flood syslog
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: SMF created a CCB to create smfRollbackElement object, but CCB was aborted due to IMM sync request
-
smf: Improve error logging when applying a CCB
-
commit b13a65123bfddcc6f5105fe340131e3bd8a5ac70 Author: Lennart Lund lennart.lund@ericsson.com Date: Thu Apr 12 17:11:59 2018 +0200 smf: Improve error logging when applying a CCB [#2832] When applying a CCB fail the return code is SA_AIS_ERR_FAILED_OPERATION. There is a number of reasons for this return code. Add logging of the reason. Also add logging if failing to delete a node group where the return code is othervise ignored.
-
smf: Improve error logging when applying a CCB [#2832]
-
smf: Improve error logging when applying a CCB
-
smf: Improve error logging when applying a CCB [#2832]
-
smf: Improve error logging when applying a CCB
-
I suggest that also the following is considered: 1. Immnd: Handle old already timed out requests from a client. An example: A client has requsted to create a runtime object. The immnd is for some reason so slow in answering the request so the reply has already been timed out by the imm agent (mds reply timeout). Because of the timeout the client does not know wether the object was created or not and has cancelled the operation that needed the object. If this object is created anyway by immnd we have...
-
log: Handling of IMM OI BAD HANDLE in log server is incorrect
-
commit a8f5bb5bb6fe348942bce37b2388f25520fdbd16 Author: Lennart Lund lennart.lund@ericsson.com Date: Thu Apr 5 14:28:20 2018 +0200 log: Handling of IMM OI BAD HANDLE in log server is incorrect [#2799] Recovery of OI handle shall be started in all places where BAD HANDLE can be returned. Creation of OI must be done in background thread. Ongoing creation must be possible to stop e.g if server is becoming standby
-
log: Handling of IMM OI BAD HANDLE in log server is incorrect [#2799]
-
log: Handling of IMM OI BAD HANDLE in log server is incorrect [#2799]
-
log: Handling of IMM OI BAD HANDLE in log server is incorrect [#2799]
-
log: Handling of IMM OI BAD HANDLE in log server is incorrect
-
log: Handling of IMM OI BAD HANDLE in log server is incorrect [#2799]
-
evt: Cannot handle immnd restart when oi handle is not resurrected
-
log: Handling of IMM OI BAD HANDLE in log server is incorrect [#2799]
-
Several solutions has been discussed. One solution that is dicussed is to use the AMF feature described in the AMF PR document section; "2.2.8 Periodic Component Monitoring with Commands" and create a program that periodically reads a file and expects a timestamp to have been updated. If the timestamp is not updated within a defined time immnd is aborted (SIGABORT). The immnd is responsible to update the timestamp. The timeout should be short e.g. 1 sec
-
log: Handling of IMM OI BAD HANDLE in log server is incorrect
-
imm: A client may not be informed about an invalidated OI if it becomes invalid without an immnd restart
-
log: Not thread safe handling of global variables
-
imm: A client may not be informed about an invalidated OI if it becomes invalid without an immnd restart
-
imm: A client may not be informed about an invalidated OI if itbecomes invalid without an immnd restart
-
imm: A client may not be informed about an invalidated OI if it becomes invalid without an immnd restart
-
LOG: Fix cyclic crash when starting standby and OI is not active
-
commit e4c94a457e6a373d4641659390dde259056264a5 Author: Lennart Lund lennart.lund@ericsson.com Date: Tue Mar 13 13:38:09 2018 +0100 log: Fix cyclic crash when starting standby and OI is not active [#2711] Fix cyclic reboot caused by reading an IMM RT object when the OI is down
-
log: Fix cyclic crash when starting standby and OI is not active [#2711]
-
log: Fix cyclic crash when starting standby and OI is not active [#2711]
-
log: IMM OI BAD HANDLE incorrectly propagated to log client
-
log: IMM OI BAD HANDLE incorrectly propagated to log client [#2799]
-
log: IMM OI BAD HANDLE incorrectly propagated to log client
-
smf: Add capability to redo CCBs that fail [#1398]
-
LOG: Fix cyclic crash when starting standby and OI is not active
-
log: Fix cyclic crash when starting standby and OI is not active [#2711]
-
LOG: Fix cyclic crash when starting standby and OI is not active
-
LOG: Fix cyclic crash when starting standby and OI is not active
-
LOG: Add retry logic for RT object creation call.
-
After some investigation I found that the problem occurs if a stream including its RT object is succesfully created and then the OI handle becomes invalid. As long as the OI handle is invalid no OI exist for the RT object. If the object is read during this time all attributes will be empty. This includes the class name. If the standby (SC-2) is started while the OI handle is still invalid then standby will SEGV during cold sync. This will happen when immutil_get_className(&objectname) is called....
-
amf: Investigate why error msg below is logged twice as NO and ER
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Add capability to redo CCBs that fail [#1398]
-
smf: Smfnd does not protect global variables used in more than one thread
-
commit 924aa6e5046621c2c299f22d1943b8f1b0148b4a Date: Tue Dec 5 12:16:50 2017 +0100 smf: Fix handling of MDS events in smfnd [#2723] The global smfd_dest (in cd struct) shall be restored with MDS event NCSMDS_UP and NCSMDS_NEW_ACTIVE (is set to 0 with event NCSMDS_DOWN)
1 >