My understanding is as follows: the signature you’ve highlighted would check the content of the packet. If it sees a log-in attempt with that username, it would add to the flowvar usernamecount; next step, it will check if that same variable is greater than 5, and alert if so.
If the packet doesn’t contain that username, then, indeed, there will be no alert in that case, but the first time the username is seen more than 5 times, and any subsequent times, my understanding is that we would see an alert.
As for the example for active users
alert tcp any any -> any any (msg:"Username Logged out"; content:"logout jonkman"; \
flowint: usernamecount, -, 1; flowint:usernamecount, >, 5;)
It will reduce from the flowvar when it seems the logout (assuming a protocol that indicates the username logged out), then compare usernamecount and check if it’s still greater than 5, and only alert on that case.
Can you elaborate a bit more on the scenario you have in mind?
For most standard content and buffers, but, from the docs and tests, it seems to me that flowints in a rule will be processed serially. So, if the rule said flowint: usernamecount, +, 1; flowint:usernamecount, >, 5;, flowint: usernamecount, +, 1; should be processed first and then the read op rule.
Would be good to test though if you can find inconsistencies in this. suricata-verify tests are welcome for different usecases