Description of problem: Today if you collect logs using this method (oc adm node-logs) you only get the node/journal logs for the current boot. Having an option or the ability to span multiple boots/reboots will help with our ability to troubleshoot and diagnose issues. How reproducible: 100% Steps to Reproduce: 1. Get logs for a service (oc adm node-logs --role master -u NetworkManager.service) 2. Reboot a master or all masters 3. Get logs for a service (oc adm node-logs --role master -u NetworkManager.service) Actual results: you only get the logs from the current boot. Expected results: We should have an option or flag to request logs from prior boots. Additional info: Where feature was added: https://github.com/openshift/origin/commit/d9dc6892d395c239b19831641218ca047e74ad94
Fix in https://github.com/openshift/origin/pull/22668
Updated version of this is now in these 2 PRs: - https://github.com/openshift/origin/pull/22668 - kubelet part - https://github.com/openshift/oc/pull/45 - oc part
confirmed with payload 4.2.0-0.nightly-2019-08-21-210916, the issue has fixed, after restart a master , we could see all the old logs, like this: [root@dhcp-140-138 ~]# oc adm node-logs ip-10-0-163-216.xxxxx -u NetworkManager.service -- Logs begin at Thu 2019-08-22 02:22:25 UTC, end at Thu 2019-08-22 05:32:32 UTC. -- Aug 22 02:27:20 localhost systemd[1]: Starting Network Manager... Aug 22 02:27:20 localhost NetworkManager[1017]: <info> [1566440840.3260] NetworkManager (version 1.14.0-14.el8) is starting... (for the first time) Aug 22 02:27:20 localhost NetworkManager[1017]: <info> [1566440840.5736] dhcp4 (ens3): domain name 'us-east-2.compute.internal' ....... Aug 22 05:31:42 ip-10-0-163-216 NetworkManager[983]: <info> [1566451902.4958] manager: (vethfcd84864): new Veth device (/org/freedesktop/NetworkManager/Devices/16) Aug 22 05:31:42 ip-10-0-163-216 NetworkManager[983]: <info> [1566451902.5056] device (vethfcd84864): enslaved to non-master-type device ovs-system; ignoring
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2922
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days