- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have just upgraded to mpss 3.4.1 and experience that my /etc/passwd file of 1300 entries cannot be processed in reasonable time during the micctrl --initdefaults. It runs with 100% cpu so it must be doing something.
Removing all users except myself make the process run quickly. Is there a limit on the number of users in the host's passwd file ?
It worked fine when using the 3.1.2 version of mpss, but there was an upper limit on the UID numbers that needed to be set. Does this still apply ?
Suggestions ?
Ole
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The problems contiune, the problem with UID higher than 65534 persist in version 3.4.1. Only about 1/3 of my entries make it to the mpss passwd file at /var/mpss/mic0/etc.
In addition the micctrl --initdefaults just hangs when I continue to use the long passwd file. Before thete was a sysconfig entry that could be changed. I cannot find this anymore.
Ole
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ole,
I had your question moved to a separate topic so that we could follow up better.
With MPSS 3.3 and 3.4, the option to specify a range of UIDs for passwd has been removed. In general, you will not want to remake the passwd file for your coprocessor each time you update the MPSS. If the passwd file already exists, then 'micctrl --initdefaults', without the --users option, shouldn't touch passwd for the coprocessor.
If you need to create /etc/passwd for the coprocessor from scratch and you have a large number of users, what should you do? As you have noticed, if you have a large number of users and you are making the passwd file from scratch (in other words, using 'micctrl --initdefaults --users=overlay' or, if there is no /var/mpss/micX/etc/passwd for X=coprocessor number), micctrl can take a long time or even hang. In this case you can use:
micctrl --initdefaults --users=none
or
micctrl --userupdate=none
This will create a passwd file with only the minimal set of users including root, sshd, micuser, nobody and nfsnobody. Then you can add individual users users using:
micctrl --useradd=<name> --uid=<uid> --gid=<gid> [--home=<dir>] [--comment=<string>] [--app=<exec>] [--sshkeys=<keydir>] [--nocreate] [--non-unique] [mic card list]
Since there are a large number of users, you could put this in a shell script and loop over all the names in the hosts passwd file. Alternately, you can edit /var/mpss/micX/etc/passwd and /var/mpss/micX/etc/shadow for each coprocessor X by hand. If you do this and you are not NFS mounting the users' home directories, you will also need to create the home directories in /var/mpss/micX/home for each user and copy over the .ssh directory from the user's host home directory into their coprocessor home directory. If you do this, you will also need to make sure the login shell for each person in the passwd file is a shell that is available on the coprocessor (such as bash). Using micctrl is the recommended solution, but do what works for you.
Over time, as you add and delete users from the host and want to add or delete them from the coprocessor as well, you can use:
micctrl --userupdate=merge [--pass=<none | shadow>] [--nocreate] [mic card list]
This will add users who are in the host passwd file but not the coprocessor passwd file and delete users who are in the coprocessor passwd file but not the host passwd file.
To keep the group file up-to-date, you would use:
micctrl --groupadd=<name> --gid=<gid> [mic card list]
You can find information on all these commands in the MPSS User's Guide or on the man page for micctrl.
If you find that micctrl tries to remake the passwd file from scratch even though it already exists and you didn't use the --users=overlay option, this is a bug and should be reported.
If you find that 'micctrl --userupdate=merge' or micctrl --useradd' can't handle UIDs as large as you need them, this should also be reported.
Hope this helps.
Frances

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page