The SCSI devices in the logs made me think that this is an environment with standard zFCP storage - iSCSI is of course d different thing.
Sharing /etc/fstab and some more details about the disk and filesystem layout could be helpful. I assume that the second system has a similar configuration than the first one (again iSCSI)? I saw that lszdev shows several DASDs - is /var/log is placed on a local (DASD) disk or on an iSCSI volume? If the disk/fs for rsyslogd is on iSCSI (especially on sdq or sdaa in your example) I think this problem is likely a follow-on problem of the disk issues that are reported: Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664541] sd 3:0:0:2: [sdt] tag#81 CDB: Inquiry 12 01 c9 00 fe 00 Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664542] sd 3:0:0:2: [sdt] tag#81 Sense Key : Illegal Request [current] Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664543] sd 3:0:0:2: [sdt] tag#81 Add. Sense: Invalid field in cdb Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664656] sd 4:0:0:2: [sdq] tag#32 Done: SUCCESS Result: hostbyte=DID_TARGET_FAILURE driverbyte=DRIVER_OK Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664657] sd 4:0:0:2: [sdq] tag#32 CDB: Inquiry 12 01 c9 00 fe 00 Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664657] sd 4:0:0:2: [sdq] tag#32 Sense Key : Illegal Request [current] Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664658] sd 4:0:0:2: [sdq] tag#32 Add. Sense: Invalid field in cdb Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664773] sd 5:0:0:2: [sdaa] tag#48 Done: SUCCESS Result: hostbyte=DID_TARGET_FAILURE driverbyte=DRIVER_OK Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664774] sd 5:0:0:2: [sdaa] tag#48 CDB: Inquiry 12 01 c9 00 fe 00 Sep 15 17:16:52 ilzlnx4 kernel: [3725853.664775] sd 5:0:0:2: [sdaa] tag#48 Sense Key : Illegal Request [current] The sense codes 3 4 and 5 of the driver byte point to: 3 MEDIUM ERROR 4 HARDWARE ERROR 5 ILLEGAL REQUEST (https://www.t10.org/lists/2sensekey.htm) Such errors occur in your initial log (bug description) as well as in the attached rsyslog.debug output. If you have system with local storage only (e.g. DASD only) I would assume that you will not face such rsyslogd issues. Can you please try or check on an existing non-iSCSI system, too? And btw. did you ran 'multipath -ll' (and maybe 'lvs') when the problem happened and rsyslogd stopped? Were any failures ('Failed Path' or 'device-mapper: multipath: Failing path') reported? I at least saw some access timeouts in the logs. (Just as a side note: this problem is reported on 'Launchpad', the bug and issue tracking system of Canonical/Ubuntu. In case the problems occurs on a production system, it's recommended to open a salesforce case based on an UA account. That would provide dedicated severity levels and response times.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896575 Title: [UBUNTU 20.04] syslog daemon stop running unexpectedly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1896575/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
