You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To use the PSAMPLE netlink channel, "sudo modprobe psample" must have been executed on the server. If it has not, then mod_psample will fail to open and join the channel. The modprobe can be added to the server boot sequence, or it can be added to the systemd unit file to run when hsflowd is started.
But what happens when "sudo modprobe psample" is only executed after hsflowd has already been started?
If hsflowd has retained root privileges, then the 15S retry (as currently implemented) will succeed, but if privileges have been dropped in the interim then mod_psample will get "Operation not permitted" when it tries to join the group. And the error will be repeated every 15S.
The question is: should mod_psample force an exit if it finds itself in this predicament? Or is it better to keep going on the assumption that there may be other modules providing useful data?
If a module is referenced in the config but has not been compiled then hsflowd will just print an error message and go on, so if we are to follow that precedent then the current practice of printing an error and going on would be consistent.
It might have been tempting to include the modprobe in the default systemd unit file, but doing anything to the kernel that might not be strictly necessary seems wrong.
And adding an extra step to the unit file to ask hsflowd if the modprobe is going to be needed seems convoluted.
So I think we leave it the way it is and try to document the dependency clearly, but I'll leave this issue open for comment.
The text was updated successfully, but these errors were encountered:
To use the PSAMPLE netlink channel, "sudo modprobe psample" must have been executed on the server. If it has not, then mod_psample will fail to open and join the channel. The modprobe can be added to the server boot sequence, or it can be added to the systemd unit file to run when hsflowd is started.
But what happens when "sudo modprobe psample" is only executed after hsflowd has already been started?
If hsflowd has retained root privileges, then the 15S retry (as currently implemented) will succeed, but if privileges have been dropped in the interim then mod_psample will get "Operation not permitted" when it tries to join the group. And the error will be repeated every 15S.
The question is: should mod_psample force an exit if it finds itself in this predicament? Or is it better to keep going on the assumption that there may be other modules providing useful data?
If a module is referenced in the config but has not been compiled then hsflowd will just print an error message and go on, so if we are to follow that precedent then the current practice of printing an error and going on would be consistent.
It might have been tempting to include the modprobe in the default systemd unit file, but doing anything to the kernel that might not be strictly necessary seems wrong.
And adding an extra step to the unit file to ask hsflowd if the modprobe is going to be needed seems convoluted.
So I think we leave it the way it is and try to document the dependency clearly, but I'll leave this issue open for comment.
The text was updated successfully, but these errors were encountered: