Virtualmin delete-user multiple users

OS type and version CentOS Linux 7.9.2009
Virtualmin version 7.9.0

How can I delete multiple users using delete-user command?
One of my hosts has too many users and it is killing virtualmin/usermin.

I tried virtualmin delete-user --domain DOM --user US1 & virtualmin delete-user --domain DOM ... but I get error “failed to lock file postfix/virtual after 5 mins” and it breaks the process.

Can you help me somehow? Using virtualmin web and multiselect is impossible as it takes forever to load user page.


virtualmin delete-user --domain DOM --user US1 --user US2 --user US3

This would send the command to the background. In your example you could have used &&, but it would be slower than using multiple --user parameters.

can webmin users and ground be used? you can multiselect there.
Opps read what you said, why would it be so slow to load, you have issues if thats slow.

found this

Thank you Illia,
I tried your command but it seems it removes only the last user on the list.

Because of (probably) some issues I have, this delete process takes about 6-10 minutes per user. My idea was to list 50 and put it in background so I don’t need to wait.

Do you think it might be faster if I disable server until I clear these unwanted users?

If you use the command I exampled, it should work. It worked for me.

How many domains and users do you have?

I understand it should - just it doesn’t do for me :slight_smile: I use short username, not full like fname.lname@domain.qwe maybe that is the reason. I’ll try that.

I need to remove 5000 users from one domain. (There are 12.000 in total on that one domain now)

how? are they being created internally or externally by an application.
That number of users seems unmanageable by any means!

I have made python script that picks and parse csv file uploaded by my client. Then I use virtualmin api to add those users. It is for their employees and that fluctuates. I forgot to remove those who left - so now I need to clear 5000 :slight_smile:

It started few years ago. Back then they were about 500-600 users. Minimal usage, just to get one mail monthly. But they grew over the years.


It is nice to know that Virtualmin can be pushed to such limits. And only yesterday, in an unrelated incident, I was speaking with an admin in Germany who has integrated Virtualmin with a telco to offer a very unique solution and we were discussing how it could be made to scale. He has about 200 virtual servers on a single install of Virtualmin and I told him that I had managed to scale a dedicated server to almost a thousand virtual serves.

Kudos to the Virtualmin team who keep Virtualmin light by working directly with the config files of a server, unlike some panels which go about it in a round-about manner which consumes more resources to run the panel and limits the things that an admin can do by editing files directly on a system.

1 Like

And in addition to that consideration, how much mail is stored in the user / mailbox that you wish to delete? If there is lots and lots of mail then it might take longer to delete.

Now there is an idea. Instead of disabling the entire virtual server to speed things up, you could disable the login of a user of the virtual server.

See if disabling a user is faster on your very loaded server than deleting a user / mailbox. Both produce similar results - the user’s access to the mailbox is denied and mail sent to the mailbox will bounce.

Thanks, I’ll try that!

They are all basically mostly around 10-15Mb, few 35Mb max.

That’s not much at all and is probably not the reason that deleting a user / mailbox is slow on your server.

I was just now checking processes, and virtualmin delete-users boinks processor to 96%. Not sure why though.

I wouldn’t worry if it was just a quick and short lived surge. Perl will do that to a system and I sometimes think that it is a good thing.

But if it takes 6 minutes to delete a user and your processor is at 96% during that time, that’s a different matter altogether, even if you have multiple cores.

There was a bug in Virtualmin 7.9.0 that was later fixed in Virtualmin 7.10.0. Try upgrading to the latest version and checking again. It should work …