Software Archive
Read-only legacy content
17061 Discussions

I have just upgraded to mpss 3.4.1 and experience that my /etc/passwd file of 1300 entries cannot...

Ole_Saastad
Beginner
651 Views

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

 

 

0 Kudos
2 Replies
Ole_Saastad
Beginner
651 Views

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

 

0 Kudos
Frances_R_Intel
Employee
651 Views

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

 

 

0 Kudos
Reply