Project

General

Profile

Feature #14141

Updated by Toomas Soome about 2 months ago

With slightly older screen, I did notice the issue in output of w and who: 
 <pre> 
 tsoome@openindiana:/code/illumos-gate$ w 
 00:04:43        2 users,    load average: 0,93, 1,06, 1,05 
 User       tty        login@           idle      JCPU      PCPU what 
 tsoome     pts/2      23:23:57            2         1         0 /usr/bin/bash 
 tsoome     pts/1      23:52:22            0         0         0 w 
 tsoome     pts/3      23:22:05            0         0         0 - 
 tsoome     pts/3      23:22:05            0         0         0 - 
 tsoome@openindiana:/code/illumos-gate$ who 
 tsoome       pts/2          okt    6 23:23      (10.7.33.28) 
 tsoome       pts/1          okt    6 23:52      (10.7.33.28) 
 tsoome       pts/3          okt    6 23:22      (:pts/2:S.0) 
 tsoome       pts/3          okt    6 23:22      (:pts/2:S.0) 
 tsoome@openindiana:/code/illumos-gate$  
 </pre> 

 This system was built However, there are no processes with gcc 10 on sparc, pts/3 terminal line... 
 <pre> 
 tsoome@openindiana:/code/illumos-gate$ ps -ef | grep pts 
     root    7953    5038     0 23:56:16 pts/2         0:00 sudo -s 
   tsoome    8000    7924     0 00:05:58 pts/1         0:00 ps -ef 
   tsoome    8001    7924     0 00:05:58 pts/1         0:00 grep pts 
   tsoome    5038    5037     0 23:23:58 pts/2         0:00 -bash 
     root    7954    7953     0 23:56:20 pts/2         0:00 /usr/bin/bash 
   tsoome    7924    7923     0 23:52:23 pts/1         0:00 -bash 
 tsoome@openindiana:/code/illumos-gate$ 
 </pre> 

 While investigating, I found those extra entries are from utmpx, with ut_type USER_PROCESS and the problem is not about w and who commands, but about 32-bit ABI - gcc 10 does not implement complementing 32-bit signed data ut_exit.e_exit set to 64-bit (as does gcc 4.4.4). From one hand this is bug, but NONROOT_USRX (described in this particular case, utmpx structure section of GETUTXENT(3C)). 

 I think, we can work around by building utmpd as 64-bit binary. It is a bit odd reason, but as good as any other IMO. should filter out such utmpx entries (for example, finger already does this). 

Back