Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reservation checks look at system users #354

Open
tboinski opened this issue Jan 14, 2022 · 3 comments
Open

Reservation checks look at system users #354

tboinski opened this issue Jan 14, 2022 · 3 comments

Comments

@tboinski
Copy link
Collaborator

The system reports reservation violations for system users like gdm, root or even "None" user. This generates unnecessary spam.

@roscisz
Copy link
Owner

roscisz commented Jan 14, 2022

Thanks for your feedback.

A quick fix could be achieved by editing tensorhive/core/managers/InfrastructureManager.py, in ignored_processes there are hard-coded names of processes that should be ignored. Maybe in your setup the Xorg processes have a different name and you could add them. Please let me know if it helps.

Anyhow, I will leave the issue open with the following comment:

It should be possible to provide a custom whitelist of system users that would be ignored by infrastructure manager... or only by protection service? The list should be configurable via configuration files.

@tboinski
Copy link
Collaborator Author

The question is should this be a process list or a list of usernames, as processes can be system dependent. In m setup the likely culprit was /usr/bin/gnome-shell.

@tboinski
Copy link
Collaborator Author

In current develop branch the system behave differently. Currently the protection service asks the User model for user email. If the violator is the system user (e.g. root or gdm) the User model throws an exception and even admin emails are not sent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants