Bug #8239
closedInventory messes up Last logged in user date when last user was a reboot
Description
Hi,
The whole story began after having a look at the webapp log file after a newly installed system's inventory was processed.
Found in version rudder-agent-2.11.16, but I tested it is the same on current latest 3.1.9.
The webapp logfile shows this WARN:
[2016-05-04 10:25:55] WARN com.normation.inventory.provisioning.fusion.FusionReportUnmarshaller - Error when parsing date for last user loggin. Awaited form at is EEE MMM dd HH:mm, found: 3.0.101-0.40-def Wed May 4
After having a look at the received inventory, it contained this part:
<HARDWARE> <ARCHNAME>x86_64-linux-thread-multi</ARCHNAME> <CHASSIS_TYPE>Rack Mount Chassis</CHASSIS_TYPE> <CHECKSUM>131071</CHECKSUM> <DATELASTLOGGEDUSER>3.0.101-0.40-def Wed May 4</DATELASTLOGGEDUSER> [...]
This looks suspicios, it is shifted by one column, so I got a feeling this is something about bad parsing.
The issue caused by this is located in the FusionInventory/Agent/Task/Inventory/Generic/Users.pm:
147 sub _getLastUser { 148 my (%params) = ( 149 command => 'last', 150 @_ 151 ); 152 153 my $last = getFirstLine(%params); 154 return unless $last; 155 return unless 156 $last =~ /^(\S+) \s+ \S+ \s+ \S+ \s+ (\S+ \s+ \S+ \s+ \S+ \s+ \S+)/x; 157 158 return { 159 LASTLOGGEDUSER => $1, 160 DATELASTLOGGEDUSER => $2 161 }; 162 }
This parses the output of "last", but if the last user was a reboot (yes, reboots tend to happen sometimes... :D), the column is shifted by one, as visible on this example:
# last admin pts/0 server.fqdn Wed May 4 10:41 still logged in reboot system boot 3.0.101-0.47.71- Wed May 4 10:36 (00:06) reboot system boot 3.0.101-0.40-def Wed May 4 10:09 (00:15)
The culprit is "system boot", which messes up the regex in L156.
The inventory was pulled at 10:20, which time the last line matches the "reboot", so my proposed fix is to check if the last line begins with "^reboot.*system boot" and just bail out for that.
PS: You have a typo as "login": Error when parsing date for last user loggin.
It will actually be "resolved" after a real user is logged in, and the inventory after that will be good again, but the main reason to have rudder is not having to login to the system, and I could imagine there are actually rudder-managed systems, that do not have interactive user logins, so this might be worth to look into it :-)