I need to receive a notification when authentication on the client happens.
I have an item with key:
log[/var/log/auth.log,(sshd.*)?(Accepted)]
Also I have trigger with key:
{test.test.ru:log[/var/log/auth.log,(sshd.*)?(Accepted)].str(Accepted,#1)}=1
I need that there will be only notification without raising a problem. With my config I always should deactivate the problem and I receive a second notification I don't need. How can I make notification without an obligation to close the problem or to receive second notification?
Suppose that this is impossible... What meets my requirements most is to make a specific action for this trigger and do not make a recovery step for it.
In the trigger configuration, you can select "Problem Event Generation Mode" = "Multiple" to have multiple problem / notification.
An Action can have no Recovery Operation and works just fine.
https://www.zabbix.com/documentation/current/manual/config/triggers/trigger
Related
I need trigger able to detect that polled Zabbix agent items does not returns data.
For zabbix trapper items this functionality is covered by nodata() function (Heartbeat lost detection in Zabbix documentation) but I need similar functionality supported for Zabbix agent items.
For example, a have defined Zabbix agent UserParameter:
UserParameter=custom.mssqlping,/usr/local/scripts/mssqlping.sh.
The script mssqlping.sh returns 0/1. I need to cover situation when mssqlping.sh script is broken and returns empy string, which is not stored in zabbix because it is not number.
How to detect that periodically polled item data are no longer coming?
It is not that it's not stored that creates the problem but the fact that it is not being considered as a valid item anymore so you can't trigger anything out of it. There is a plenty of related bug reports related to it. AFAIk your options:
Adjust the script to return a numeric value in case of errors
Use 2.2's "internal events" to detect the "becomes unsupported" event
Make and external script that will query the database directly and will notify you on its own or triggering a condition through zabbix's trappers
Or the option here is to trigger based on nodata()
from: https://www.zabbix.com/forum/zabbix-help/41652-zabbix-trigger-timeout?p=245422#post245422
{myserver:example.iregexp("/string/",1m)}=1 AND {myserver:example.nodata(1m)}=0
some more reading: https://zabbix.org/wiki/Trigger_examples
I have built a function that checks to see if a primary key is already linked with a foreign key. If it is already linked it prompts the user to see if they want to overwrite the existing value. If it isn't already linked it just saves the value into the DB without ever prompting the user.
The issue that I am running into is that once my function has already performed the update, the DB form also tried to perform the update, resulting in a duplicate key error message.
I realize I could just unbind the controls on the on the form so that they didn't try to perform the update function, though for easy of use I want to keep those controls bound. So what other means do I have of canceling the form from performing the update and possibly to just get it to refresh with the new information? I am sure this is probably an easy thing to do though I don't really know the terms to search in google in order to find the answer.
If you want to stay with this model the best you can do is to hook up on Form.BeforeUpdate Event and set the Cancel flag to true, as well as call DoCmd.CancelEvent method.
When your code executed, it can call the Refresh method to query new values.
Hope this answers your question and solves the issue you have.
I have to modify an Oracle Form but cannot find my way to start.
What is the start up order for a standard form? That is which event, trigger etc will be called at form load, canvas load, etc. I assume that it is When-New-form-Instance but a cannot get it to stop at a break point on the first line of this trigger.
I am getting
FRM-40735 ON_ERROR trigger raised unhandled exception ORA-06508
Which I suspect means I do not have my environment set up correctly but I have done the same as others at this site. So I thought to start with debugging and try to identify which call is failing
PRE-FORM fires before WHEN-NEW-FORM-INSTANCE. Check what's defined in PRE-FORM trigger.
Also, your ON-ERROR trigger is giving a ORA-06508 error, so might want to check what program unit is being referred to in the ON-ERROR trigger
To get a start in trying to find the source of the error, try disabling custom code in forms. If the error does not persist when custom code is disabled, you'll have to start tracing through CUSTOM.PLL to find the source of the issue.
I have a simple accessor in my class:
public function get loggedIn():Boolean
{
var loggedIn:Boolean = somePrivateMethodToCheckStatus();
return loggedIn;
}
The API I'm now working with checks login status in an asynchronous fashion:
API_Class.addEventListener(API_Class.LOGIN_STATUS,onStatusCheck);
API_Class.checkLoginStatus();
function onStatusCheck(evt:API_Event):void
{
//evt.loggedIn == true or false
}
Is there a way I can perform this asynchronous request without exiting my accessor?
Simple answer: No, there is not. You will have to set up login verification in an asynchronous fashion.
I am a bit curious: Why is there a need to repeatedly poll the login status remotely? If your user logged in from within the Flash application, the status should be known. Same goes for logging out. If login and logout is handled from outside the Flash app, why not implement a notification mechanism (via JavaScript or socket connection)?
Also, if not being logged in prevents users from performing actions on the server, you could check for authorization on the server, whenever remote calls are made, and return an error if the session has expired. This would still be more efficient than repeatedly polling status info.
Not really, no. Flash runs in a single thread, and every function has to finish before events etc will be called.
One (sort of) solution would be to return three values; "yes", "no" and "pending". If it's pending the loggedIn()-method would start a check, and the client of that method should check again in a little while.
Another way would be to have the loggedIn-method send the answer to a callback instead. Eg "getLoggedInStatus(callback:Function)"
You may be interested in http://www.as3commons.org/as3-commons-eventbus/index.html
It is a handy lib that focuses on asynchronous jobs.
Background: We are in the process of writing a registration/payment page, and our philosophy was to code all validation and error checking on the server side first, and then add client side validation as a second step (un-obstructive jQuery).
We wanted to disable double clicks server side, so we wrote some locking, thread-safe code to handle simultaneous posts/race conditions. When we tried to test this, we realized that we could not cause a simultaneous post or race condition to occur.
I thought that (in older browsers anyway) double clicking a submit button worked as follows:
User double clicks submit button.
Browser sends a post on the first click
On the second click, browser cancels/ignores initial post, and initiates a second post (before the first post has returned with a response).
Browser waits for second post to return, ignoring initial post response.
I thought that from the server side it looked like this: Server gets two simultaneous post requests, executes and responds to them both (unaware that no one is listening to the first response).
From our testing (FireFox 3.0, IE 8.0) this is what actually happens:
User double clicks submit button
Browser sends a post for the first click
Browser queues up second click, but waits for the response from the first click.
Response returns from first click (response is ignored?).
Browser sends a post for the second click.
So from a server side: Server receives a single post which it executes and responds to. Then, server receives a second request which it executes and responds to.
My question is, has this always worked this way (and I'm losing my mind)? Or is this a new feature in modern browsers that prevents simultaneous posts to be sent to the server?
It seems that for server side double click prevention, we don't have to worry about simultaneous posts or race conditions. Only need to worry about queued up posts.
A similar situation that you need to handle (that the javascript disable-submit-button solution doesn't cover) is the one where the user clicks Submit, the server processes the request, but while it's processing the user's internet connection goes down (perhaps they're on a train going into a tunnel).
When the train comes out of the tunnel, the user doesn't know whether their transaction succeeded or not - they pressed the button, but nothing changed on the page (or perhaps they got a "Try again" page). The natural thing for them to do is click Submit again (or the "Try again" button).
The best way to handle this situation is to include a unique transaction id in the form (in a hidden field). Generate this id randomly, and when a transaction is successfully processed, store it in the database in a list of completed transactions.
Then when you get a POST, check whether this transaction has already been seen - and if it has, skip straight to the status page. Roughly:
BEGIN TRANSACTION
SELECT *
FROM completedTransactions
WHERE userId = ... AND transactionId = ...
<if we got a result - display results of previous transaction>
<otherwise - process the request as normal>
INSERT INTO completedTransactions (userId, transactionId)
VALUES (....)
END TRANSACTION
This has the advantage that (provided you have a database that properly supports transactions - and since you're processing payments I hope you do!) you don't need to do any sort of threading or locking - things "just work".
(though be careful - some database systems can arbitrarily abort your transactions if there is a concurrency problem - but this (rare) situation is easily dealt with using a retry loop...)
As to testing double clicks from browsers: does it make any difference if you press the "stop" button between the two "submit" clicks?
this may be a stupid response, but why dont you just disable the submit button with javascript on click, so you dont have to worry about multiple clicks. i usually do this on most forms i make and it seems to solve the problem.
you already said you are using javascript so thats not the issue right?
As long as the request is in its connecting or sending stage, clicking on submit during the first submission cancels the request, starting a new one without the server 'knowing'.