What is the purpose of the 10th column of the `last` command's output?
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
I see a suspicious pattern in a last command output on RHEL:
$ last reboot
reboot system boot 3.10.0-514.21.1. Wed Dec 13 10:25 - 11:53 (01:28)
reboot system boot 3.10.0-514.21.1. Mon Oct 30 16:23 - 11:53 (43+20:30)
reboot system boot 3.10.0-514.21.1. Fri Oct 20 16:53 - 11:53 (53+20:00)
reboot system boot 3.10.0-514.21.1. Mon Oct 16 09:21 - 11:53 (58+03:32)
reboot system boot 3.10.0-514.21.1. Fri Aug 25 15:53 - 11:53 (109+21:00)
reboot system boot 3.10.0-514.21.1. Tue Aug 22 15:36 - 11:53 (112+21:16)
reboot system boot 3.10.0-514.21.1. Fri Jul 21 16:38 - 11:53 (144+20:15)
reboot system boot 3.10.0-514.21.1. Fri Jun 9 15:00 - 16:18 (42+01:17)
reboot system boot 3.10.0-514.21.1. Mon Jun 5 11:20 - 16:18 (46+04:57)
reboot system boot 3.10.0-514.21.1. Thu Jun 1 09:49 - 16:18 (50+06:28)
reboot system boot 3.10.0-514.el7.x Wed May 31 17:46 - 09:49 (16:02)
Namely, the 10th column shows the same time datum on several rows (e.g., 11:53 seven times, and 16:18 three times).
The man page does not explain what each column should represent.
Do you know the purpose of the 10th column of the last command's output?
last
edited Dec 13 '17 at 20:48
terdon♦
122k28230403
asked Dec 13 '17 at 20:37
boardrider
1447
 |Â
show 2 more comments
up vote
3
down vote
favorite
I see a suspicious pattern in a last command output on RHEL:
$ last reboot
reboot system boot 3.10.0-514.21.1. Wed Dec 13 10:25 - 11:53 (01:28)
reboot system boot 3.10.0-514.21.1. Mon Oct 30 16:23 - 11:53 (43+20:30)
reboot system boot 3.10.0-514.21.1. Fri Oct 20 16:53 - 11:53 (53+20:00)
reboot system boot 3.10.0-514.21.1. Mon Oct 16 09:21 - 11:53 (58+03:32)
reboot system boot 3.10.0-514.21.1. Fri Aug 25 15:53 - 11:53 (109+21:00)
reboot system boot 3.10.0-514.21.1. Tue Aug 22 15:36 - 11:53 (112+21:16)
reboot system boot 3.10.0-514.21.1. Fri Jul 21 16:38 - 11:53 (144+20:15)
reboot system boot 3.10.0-514.21.1. Fri Jun 9 15:00 - 16:18 (42+01:17)
reboot system boot 3.10.0-514.21.1. Mon Jun 5 11:20 - 16:18 (46+04:57)
reboot system boot 3.10.0-514.21.1. Thu Jun 1 09:49 - 16:18 (50+06:28)
reboot system boot 3.10.0-514.el7.x Wed May 31 17:46 - 09:49 (16:02)
Namely, the 10th column shows the same time datum on several rows (e.g., 11:53 seven times, and 16:18 three times).
The man page does not explain what each column should represent.
Do you know the purpose of the 10th column of the last command's output?
last
edited Dec 13 '17 at 20:48
terdon♦
122k28230403
asked Dec 13 '17 at 20:37
boardrider
1447
that's usually the "logout" time, though I'm not sure what value makes sense for the "reboot" entry
– Jeff Schaller
Dec 13 '17 at 20:48
Thanks for the answer @jeff. Do you know if there's a man or other documentation that goes into the details of the last output format?
– boardrider
Dec 13 '17 at 20:49
for reboots, it's the time the system went down, but the durations in the last column seem like they're calculated not to the shutdown time, but to the current time (notice how the duration counter goes up 10 days between the events on Oct 30 and Oct 20, and similarly with the others).
– ilkkachu
Dec 13 '17 at 20:59
linking in: unix.stackexchange.com/q/36287/117549 and unix.stackexchange.com/q/7760/117549
– Jeff Schaller
Dec 13 '17 at 21:00
Meh, the first one has a similar output with the same ending time on multiple rows, but no explanation for it. I wonder if it's just broken records inwtmp
– ilkkachu
Dec 13 '17 at 21:12
 |Â
show 2 more comments
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I see a suspicious pattern in a last command output on RHEL:
$ last reboot
reboot system boot 3.10.0-514.21.1. Wed Dec 13 10:25 - 11:53 (01:28)
reboot system boot 3.10.0-514.21.1. Mon Oct 30 16:23 - 11:53 (43+20:30)
reboot system boot 3.10.0-514.21.1. Fri Oct 20 16:53 - 11:53 (53+20:00)
reboot system boot 3.10.0-514.21.1. Mon Oct 16 09:21 - 11:53 (58+03:32)
reboot system boot 3.10.0-514.21.1. Fri Aug 25 15:53 - 11:53 (109+21:00)
reboot system boot 3.10.0-514.21.1. Tue Aug 22 15:36 - 11:53 (112+21:16)
reboot system boot 3.10.0-514.21.1. Fri Jul 21 16:38 - 11:53 (144+20:15)
reboot system boot 3.10.0-514.21.1. Fri Jun 9 15:00 - 16:18 (42+01:17)
reboot system boot 3.10.0-514.21.1. Mon Jun 5 11:20 - 16:18 (46+04:57)
reboot system boot 3.10.0-514.21.1. Thu Jun 1 09:49 - 16:18 (50+06:28)
reboot system boot 3.10.0-514.el7.x Wed May 31 17:46 - 09:49 (16:02)
Namely, the 10th column shows the same time datum on several rows (e.g., 11:53 seven times, and 16:18 three times).
The man page does not explain what each column should represent.
Do you know the purpose of the 10th column of the last command's output?
last
edited Dec 13 '17 at 20:48
terdon♦
122k28230403
asked Dec 13 '17 at 20:37
boardrider
1447
I see a suspicious pattern in a last command output on RHEL:
$ last reboot
reboot system boot 3.10.0-514.21.1. Wed Dec 13 10:25 - 11:53 (01:28)
reboot system boot 3.10.0-514.21.1. Mon Oct 30 16:23 - 11:53 (43+20:30)
reboot system boot 3.10.0-514.21.1. Fri Oct 20 16:53 - 11:53 (53+20:00)
reboot system boot 3.10.0-514.21.1. Mon Oct 16 09:21 - 11:53 (58+03:32)
reboot system boot 3.10.0-514.21.1. Fri Aug 25 15:53 - 11:53 (109+21:00)
reboot system boot 3.10.0-514.21.1. Tue Aug 22 15:36 - 11:53 (112+21:16)
reboot system boot 3.10.0-514.21.1. Fri Jul 21 16:38 - 11:53 (144+20:15)
reboot system boot 3.10.0-514.21.1. Fri Jun 9 15:00 - 16:18 (42+01:17)
reboot system boot 3.10.0-514.21.1. Mon Jun 5 11:20 - 16:18 (46+04:57)
reboot system boot 3.10.0-514.21.1. Thu Jun 1 09:49 - 16:18 (50+06:28)
reboot system boot 3.10.0-514.el7.x Wed May 31 17:46 - 09:49 (16:02)
Namely, the 10th column shows the same time datum on several rows (e.g., 11:53 seven times, and 16:18 three times).
The man page does not explain what each column should represent.
Do you know the purpose of the 10th column of the last command's output?
last
edited Dec 13 '17 at 20:48
terdon♦
122k28230403
asked Dec 13 '17 at 20:37
boardrider
1447
edited Dec 13 '17 at 20:48
terdon♦
122k28230403
edited Dec 13 '17 at 20:48
terdon♦
122k28230403
edited Dec 13 '17 at 20:48
terdon♦
122k28230403
122k28230403
asked Dec 13 '17 at 20:37
boardrider
1447
asked Dec 13 '17 at 20:37
boardrider
1447
asked Dec 13 '17 at 20:37
boardrider
1447
1447
that's usually the "logout" time, though I'm not sure what value makes sense for the "reboot" entry
– Jeff Schaller
Dec 13 '17 at 20:48
Thanks for the answer @jeff. Do you know if there's a man or other documentation that goes into the details of the last output format?
– boardrider
Dec 13 '17 at 20:49
for reboots, it's the time the system went down, but the durations in the last column seem like they're calculated not to the shutdown time, but to the current time (notice how the duration counter goes up 10 days between the events on Oct 30 and Oct 20, and similarly with the others).
– ilkkachu
Dec 13 '17 at 20:59
linking in: unix.stackexchange.com/q/36287/117549 and unix.stackexchange.com/q/7760/117549
– Jeff Schaller
Dec 13 '17 at 21:00
Meh, the first one has a similar output with the same ending time on multiple rows, but no explanation for it. I wonder if it's just broken records inwtmp
– ilkkachu
Dec 13 '17 at 21:12
 |Â
show 2 more comments
that's usually the "logout" time, though I'm not sure what value makes sense for the "reboot" entry
– Jeff Schaller
Dec 13 '17 at 20:48
Thanks for the answer @jeff. Do you know if there's a man or other documentation that goes into the details of the last output format?
– boardrider
Dec 13 '17 at 20:49
for reboots, it's the time the system went down, but the durations in the last column seem like they're calculated not to the shutdown time, but to the current time (notice how the duration counter goes up 10 days between the events on Oct 30 and Oct 20, and similarly with the others).
– ilkkachu
Dec 13 '17 at 20:59
linking in: unix.stackexchange.com/q/36287/117549 and unix.stackexchange.com/q/7760/117549
– Jeff Schaller
Dec 13 '17 at 21:00
Meh, the first one has a similar output with the same ending time on multiple rows, but no explanation for it. I wonder if it's just broken records inwtmp
– ilkkachu
Dec 13 '17 at 21:12
that's usually the "logout" time, though I'm not sure what value makes sense for the "reboot" entry
– Jeff Schaller
Dec 13 '17 at 20:48
that's usually the "logout" time, though I'm not sure what value makes sense for the "reboot" entry
– Jeff Schaller
Dec 13 '17 at 20:48
Thanks for the answer @jeff. Do you know if there's a man or other documentation that goes into the details of the last output format?
– boardrider
Dec 13 '17 at 20:49
Thanks for the answer @jeff. Do you know if there's a man or other documentation that goes into the details of the last output format?
– boardrider
Dec 13 '17 at 20:49
for reboots, it's the time the system went down, but the durations in the last column seem like they're calculated not to the shutdown time, but to the current time (notice how the duration counter goes up 10 days between the events on Oct 30 and Oct 20, and similarly with the others).
– ilkkachu
Dec 13 '17 at 20:59
for reboots, it's the time the system went down, but the durations in the last column seem like they're calculated not to the shutdown time, but to the current time (notice how the duration counter goes up 10 days between the events on Oct 30 and Oct 20, and similarly with the others).
– ilkkachu
Dec 13 '17 at 20:59
linking in: unix.stackexchange.com/q/36287/117549 and unix.stackexchange.com/q/7760/117549
– Jeff Schaller
Dec 13 '17 at 21:00
linking in: unix.stackexchange.com/q/36287/117549 and unix.stackexchange.com/q/7760/117549
– Jeff Schaller
Dec 13 '17 at 21:00
Meh, the first one has a similar output with the same ending time on multiple rows, but no explanation for it. I wonder if it's just broken records in
wtmp– ilkkachu
Dec 13 '17 at 21:12
Meh, the first one has a similar output with the same ending time on multiple rows, but no explanation for it. I wonder if it's just broken records in
wtmp– ilkkachu
Dec 13 '17 at 21:12
 |Â
show 2 more comments
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
When listing reboots, the tenth column shows the last “down time†following the boot, i.e. the time at which the system was shut down, as far as last can determine. This actually involves combining multiple records from the information stored in the system; to do so, last keeps track of the last down time it’s seen, and uses that blindly when it displays a “reboot†line.
Thus if the system is shut down abruptly, the shut down time won’t be stored, and last will use the previous record instead. Looking at your results:
reboot system boot 3.10.0-514.21.1. Wed Dec 13 10:25 - 11:53 (01:28)
reboot system boot 3.10.0-514.21.1. Mon Oct 30 16:23 - 11:53 (43+20:30)
reboot system boot 3.10.0-514.21.1. Fri Oct 20 16:53 - 11:53 (53+20:00)
reboot system boot 3.10.0-514.21.1. Mon Oct 16 09:21 - 11:53 (58+03:32)
reboot system boot 3.10.0-514.21.1. Fri Aug 25 15:53 - 11:53 (109+21:00)
reboot system boot 3.10.0-514.21.1. Tue Aug 22 15:36 - 11:53 (112+21:16)
reboot system boot 3.10.0-514.21.1. Fri Jul 21 16:38 - 11:53 (144+20:15)
reboot system boot 3.10.0-514.21.1. Fri Jun 9 15:00 - 16:18 (42+01:17)
reboot system boot 3.10.0-514.21.1. Mon Jun 5 11:20 - 16:18 (46+04:57)
reboot system boot 3.10.0-514.21.1. Thu Jun 1 09:49 - 16:18 (50+06:28)
reboot system boot 3.10.0-514.el7.x Wed May 31 17:46 - 09:49 (16:02)
last found a record indicating a shut down at 11:53 on December 13, and then several records indicating a start time; so it used that single shut down time for all of them. Then it found a shut down record for 42 days after June 9, at 16:18, and used that, again several times because it didn’t find any other shut down record until 09:49 on June 1.
You can see this in the last source code; search for “lastdown†to find where it’s updated (and used).
answered Dec 14 '17 at 17:04
Stephen Kitt
143k22309372
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
When listing reboots, the tenth column shows the last “down time†following the boot, i.e. the time at which the system was shut down, as far as last can determine. This actually involves combining multiple records from the information stored in the system; to do so, last keeps track of the last down time it’s seen, and uses that blindly when it displays a “reboot†line.
Thus if the system is shut down abruptly, the shut down time won’t be stored, and last will use the previous record instead. Looking at your results:
reboot system boot 3.10.0-514.21.1. Wed Dec 13 10:25 - 11:53 (01:28)
reboot system boot 3.10.0-514.21.1. Mon Oct 30 16:23 - 11:53 (43+20:30)
reboot system boot 3.10.0-514.21.1. Fri Oct 20 16:53 - 11:53 (53+20:00)
reboot system boot 3.10.0-514.21.1. Mon Oct 16 09:21 - 11:53 (58+03:32)
reboot system boot 3.10.0-514.21.1. Fri Aug 25 15:53 - 11:53 (109+21:00)
reboot system boot 3.10.0-514.21.1. Tue Aug 22 15:36 - 11:53 (112+21:16)
reboot system boot 3.10.0-514.21.1. Fri Jul 21 16:38 - 11:53 (144+20:15)
reboot system boot 3.10.0-514.21.1. Fri Jun 9 15:00 - 16:18 (42+01:17)
reboot system boot 3.10.0-514.21.1. Mon Jun 5 11:20 - 16:18 (46+04:57)
reboot system boot 3.10.0-514.21.1. Thu Jun 1 09:49 - 16:18 (50+06:28)
reboot system boot 3.10.0-514.el7.x Wed May 31 17:46 - 09:49 (16:02)
last found a record indicating a shut down at 11:53 on December 13, and then several records indicating a start time; so it used that single shut down time for all of them. Then it found a shut down record for 42 days after June 9, at 16:18, and used that, again several times because it didn’t find any other shut down record until 09:49 on June 1.
You can see this in the last source code; search for “lastdown†to find where it’s updated (and used).
answered Dec 14 '17 at 17:04
Stephen Kitt
143k22309372
add a comment |Â
up vote
3
down vote
accepted
When listing reboots, the tenth column shows the last “down time†following the boot, i.e. the time at which the system was shut down, as far as last can determine. This actually involves combining multiple records from the information stored in the system; to do so, last keeps track of the last down time it’s seen, and uses that blindly when it displays a “reboot†line.
Thus if the system is shut down abruptly, the shut down time won’t be stored, and last will use the previous record instead. Looking at your results:
reboot system boot 3.10.0-514.21.1. Wed Dec 13 10:25 - 11:53 (01:28)
reboot system boot 3.10.0-514.21.1. Mon Oct 30 16:23 - 11:53 (43+20:30)
reboot system boot 3.10.0-514.21.1. Fri Oct 20 16:53 - 11:53 (53+20:00)
reboot system boot 3.10.0-514.21.1. Mon Oct 16 09:21 - 11:53 (58+03:32)
reboot system boot 3.10.0-514.21.1. Fri Aug 25 15:53 - 11:53 (109+21:00)
reboot system boot 3.10.0-514.21.1. Tue Aug 22 15:36 - 11:53 (112+21:16)
reboot system boot 3.10.0-514.21.1. Fri Jul 21 16:38 - 11:53 (144+20:15)
reboot system boot 3.10.0-514.21.1. Fri Jun 9 15:00 - 16:18 (42+01:17)
reboot system boot 3.10.0-514.21.1. Mon Jun 5 11:20 - 16:18 (46+04:57)
reboot system boot 3.10.0-514.21.1. Thu Jun 1 09:49 - 16:18 (50+06:28)
reboot system boot 3.10.0-514.el7.x Wed May 31 17:46 - 09:49 (16:02)
last found a record indicating a shut down at 11:53 on December 13, and then several records indicating a start time; so it used that single shut down time for all of them. Then it found a shut down record for 42 days after June 9, at 16:18, and used that, again several times because it didn’t find any other shut down record until 09:49 on June 1.
You can see this in the last source code; search for “lastdown†to find where it’s updated (and used).
answered Dec 14 '17 at 17:04
Stephen Kitt
143k22309372
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
When listing reboots, the tenth column shows the last “down time†following the boot, i.e. the time at which the system was shut down, as far as last can determine. This actually involves combining multiple records from the information stored in the system; to do so, last keeps track of the last down time it’s seen, and uses that blindly when it displays a “reboot†line.
Thus if the system is shut down abruptly, the shut down time won’t be stored, and last will use the previous record instead. Looking at your results:
reboot system boot 3.10.0-514.21.1. Wed Dec 13 10:25 - 11:53 (01:28)
reboot system boot 3.10.0-514.21.1. Mon Oct 30 16:23 - 11:53 (43+20:30)
reboot system boot 3.10.0-514.21.1. Fri Oct 20 16:53 - 11:53 (53+20:00)
reboot system boot 3.10.0-514.21.1. Mon Oct 16 09:21 - 11:53 (58+03:32)
reboot system boot 3.10.0-514.21.1. Fri Aug 25 15:53 - 11:53 (109+21:00)
reboot system boot 3.10.0-514.21.1. Tue Aug 22 15:36 - 11:53 (112+21:16)
reboot system boot 3.10.0-514.21.1. Fri Jul 21 16:38 - 11:53 (144+20:15)
reboot system boot 3.10.0-514.21.1. Fri Jun 9 15:00 - 16:18 (42+01:17)
reboot system boot 3.10.0-514.21.1. Mon Jun 5 11:20 - 16:18 (46+04:57)
reboot system boot 3.10.0-514.21.1. Thu Jun 1 09:49 - 16:18 (50+06:28)
reboot system boot 3.10.0-514.el7.x Wed May 31 17:46 - 09:49 (16:02)
last found a record indicating a shut down at 11:53 on December 13, and then several records indicating a start time; so it used that single shut down time for all of them. Then it found a shut down record for 42 days after June 9, at 16:18, and used that, again several times because it didn’t find any other shut down record until 09:49 on June 1.
You can see this in the last source code; search for “lastdown†to find where it’s updated (and used).
answered Dec 14 '17 at 17:04
Stephen Kitt
143k22309372
When listing reboots, the tenth column shows the last “down time†following the boot, i.e. the time at which the system was shut down, as far as last can determine. This actually involves combining multiple records from the information stored in the system; to do so, last keeps track of the last down time it’s seen, and uses that blindly when it displays a “reboot†line.
Thus if the system is shut down abruptly, the shut down time won’t be stored, and last will use the previous record instead. Looking at your results:
reboot system boot 3.10.0-514.21.1. Wed Dec 13 10:25 - 11:53 (01:28)
reboot system boot 3.10.0-514.21.1. Mon Oct 30 16:23 - 11:53 (43+20:30)
reboot system boot 3.10.0-514.21.1. Fri Oct 20 16:53 - 11:53 (53+20:00)
reboot system boot 3.10.0-514.21.1. Mon Oct 16 09:21 - 11:53 (58+03:32)
reboot system boot 3.10.0-514.21.1. Fri Aug 25 15:53 - 11:53 (109+21:00)
reboot system boot 3.10.0-514.21.1. Tue Aug 22 15:36 - 11:53 (112+21:16)
reboot system boot 3.10.0-514.21.1. Fri Jul 21 16:38 - 11:53 (144+20:15)
reboot system boot 3.10.0-514.21.1. Fri Jun 9 15:00 - 16:18 (42+01:17)
reboot system boot 3.10.0-514.21.1. Mon Jun 5 11:20 - 16:18 (46+04:57)
reboot system boot 3.10.0-514.21.1. Thu Jun 1 09:49 - 16:18 (50+06:28)
reboot system boot 3.10.0-514.el7.x Wed May 31 17:46 - 09:49 (16:02)
last found a record indicating a shut down at 11:53 on December 13, and then several records indicating a start time; so it used that single shut down time for all of them. Then it found a shut down record for 42 days after June 9, at 16:18, and used that, again several times because it didn’t find any other shut down record until 09:49 on June 1.
You can see this in the last source code; search for “lastdown†to find where it’s updated (and used).
answered Dec 14 '17 at 17:04
Stephen Kitt
143k22309372
answered Dec 14 '17 at 17:04
Stephen Kitt
143k22309372
answered Dec 14 '17 at 17:04
Stephen Kitt
143k22309372
answered Dec 14 '17 at 17:04
Stephen Kitt
143k22309372
143k22309372
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f410734%2fwhat-is-the-purpose-of-the-10th-column-of-the-last-commands-output%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
that's usually the "logout" time, though I'm not sure what value makes sense for the "reboot" entry
– Jeff Schaller
Dec 13 '17 at 20:48
Thanks for the answer @jeff. Do you know if there's a man or other documentation that goes into the details of the last output format?
– boardrider
Dec 13 '17 at 20:49
for reboots, it's the time the system went down, but the durations in the last column seem like they're calculated not to the shutdown time, but to the current time (notice how the duration counter goes up 10 days between the events on Oct 30 and Oct 20, and similarly with the others).
– ilkkachu
Dec 13 '17 at 20:59
linking in: unix.stackexchange.com/q/36287/117549 and unix.stackexchange.com/q/7760/117549
– Jeff Schaller
Dec 13 '17 at 21:00
Meh, the first one has a similar output with the same ending time on multiple rows, but no explanation for it. I wonder if it's just broken records in
wtmp– ilkkachu
Dec 13 '17 at 21:12