Re: SUSE FTP Server issue
Today I tried monitoring FTP server while running install script for z/VM
install and found interesting things.
So, while coping MAINT190 (190) DISK from DVD, we getting IO error.
Now there can we two reason
1) Either DVD media is bad
Solution : I copied DVD content into local disk space to see, if copy
process getting is successful and it was.
2) disk, where we coping data from DVD during the install is bad.
Solution : I tried swapping the RES volume address with some other disk
address and tried installing it but I am getting same error.
May 7 05:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18171]
CONNECT: Client 110.32.44.19
May 6 22:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18170] [root]
OK LOGIN: Client 110.32.44.19
May 6 22:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18172] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCFD00,
2076 bytes, 21.91Kbyte/sec
May 7 05:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18174]
CONNECT: Client 110.32.44.19
May 6 22:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18173] [root]
OK LOGIN: Client 110.32.44.19
May 6 22:56:59 RBLR01 vsftpd: Wed May 6 22:56:59 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF300,
4194240 bytes, 1272.70Kbyte/sec
May 6 22:57:01 RBLR01 vsftpd: Wed May 6 22:57:01 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF301,
4194240 bytes, 2097.91Kbyte/sec
May 6 22:57:03 RBLR01 vsftpd: Wed May 6 22:57:03 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF302,
4194240 bytes, 2092.73Kbyte/sec
May 6 22:57:05 RBLR01 vsftpd: Wed May 6 22:57:05 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF303,
4194240 bytes, 2093.95Kbyte/sec
May 6 22:57:07 RBLR01 vsftpd: Wed May 6 22:57:07 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF304,
4194240 bytes, 2082.88Kbyte/sec
May 6 22:57:08 RBLR01 vsftpd: Wed May 6 22:57:08 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF305,
1349784 bytes, 1030.46Kbyte/sec
May 7 05:57:09 RBLR01 vsftpd: Wed May 6 22:57:09 2015 [pid 18177]
CONNECT: Client 110.32.44.19
May 6 22:57:09 RBLR01 vsftpd: Wed May 6 22:57:09 2015 [pid 18176] [root]
OK LOGIN: Client 110.32.44.19
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:15 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:15 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:15 RBLR01 kernel: end_request: I/O error, dev hda, sector
270720
May 6 22:57:15 RBLR01 kernel: Buffer I/O error on device hda, logical
block 67680
May 6 22:57:20 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:20 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:20 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:20 RBLR01 kernel: end_request: I/O error, dev hda, sector
270724
May 6 22:57:20 RBLR01 kernel: Buffer I/O error on device hda, logical
block 67681
May 6 22:57:24 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:24 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:24 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:24 RBLR01 kernel: end_request: I/O error, dev hda, sector
270728
May 6 22:57:24 RBLR01 kernel: Buffer I/O error on device hda, logical
block 67682
May 6 22:57:29 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
Now, I am not left with any more solution I can think now. Please suggest.
On Wed, May 6, 2015 at 5:34 PM, Donald J. dona...@4email.net wrote:
The parameters would go in your vsftpd config file which is probably
in /etc or /etc/vsftpd. I no longer have a linux to look at to verify
that.
As I said, I don't think increasing timers from 60 or 300 is going to
fix your problem. 60 seconds is a long timer. You probably are
having a total hang at some point, so increasing a timer probably
won't help, but it won't hurt either.
You misunderstood what I said about netstat. Your want to do
netstat commands while your ftp is going so you can see the port
numbers in the REMOTE column. NOTHING is happening at
the time you did the netstat below. Would be best to put the
netstat in a script and put a one second delay between commands.
Only reason for netstat is to see if you are hanging on one
particular remote port number. Your netstat below only shows
local port numbers because there are no remote connections
active at
Re: SUSE FTP Server issue
Is that your only option?
I recommend putting the ckd files on a USB and loading it that way if you
are going through hmc.
I have also brought the files down to one mod 9. Not sure exactly what your
situation is.
On May 7, 2015 5:19 AM, Mainframe Mainframe mainframe1...@gmail.com
wrote:
Today I tried monitoring FTP server while running install script for z/VM
install and found interesting things.
So, while coping MAINT190 (190) DISK from DVD, we getting IO error.
Now there can we two reason
1) Either DVD media is bad
Solution : I copied DVD content into local disk space to see, if copy
process getting is successful and it was.
2) disk, where we coping data from DVD during the install is bad.
Solution : I tried swapping the RES volume address with some other disk
address and tried installing it but I am getting same error.
May 7 05:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18171]
CONNECT: Client 110.32.44.19
May 6 22:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18170] [root]
OK LOGIN: Client 110.32.44.19
May 6 22:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18172] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCFD00,
2076 bytes, 21.91Kbyte/sec
May 7 05:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18174]
CONNECT: Client 110.32.44.19
May 6 22:56:56 RBLR01 vsftpd: Wed May 6 22:56:56 2015 [pid 18173] [root]
OK LOGIN: Client 110.32.44.19
May 6 22:56:59 RBLR01 vsftpd: Wed May 6 22:56:59 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF300,
4194240 bytes, 1272.70Kbyte/sec
May 6 22:57:01 RBLR01 vsftpd: Wed May 6 22:57:01 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF301,
4194240 bytes, 2097.91Kbyte/sec
May 6 22:57:03 RBLR01 vsftpd: Wed May 6 22:57:03 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF302,
4194240 bytes, 2092.73Kbyte/sec
May 6 22:57:05 RBLR01 vsftpd: Wed May 6 22:57:05 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF303,
4194240 bytes, 2093.95Kbyte/sec
May 6 22:57:07 RBLR01 vsftpd: Wed May 6 22:57:07 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF304,
4194240 bytes, 2082.88Kbyte/sec
May 6 22:57:08 RBLR01 vsftpd: Wed May 6 22:57:08 2015 [pid 18175] [root]
OK DOWNLOAD: Client 110.32.44.19, /media/dvdrecorder/cpdvd/CKDCF305,
1349784 bytes, 1030.46Kbyte/sec
May 7 05:57:09 RBLR01 vsftpd: Wed May 6 22:57:09 2015 [pid 18177]
CONNECT: Client 110.32.44.19
May 6 22:57:09 RBLR01 vsftpd: Wed May 6 22:57:09 2015 [pid 18176] [root]
OK LOGIN: Client 110.32.44.19
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:15 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:15 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:15 RBLR01 kernel: end_request: I/O error, dev hda, sector
270720
May 6 22:57:15 RBLR01 kernel: Buffer I/O error on device hda, logical
block 67680
May 6 22:57:20 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:20 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:20 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:20 RBLR01 kernel: end_request: I/O error, dev hda, sector
270724
May 6 22:57:20 RBLR01 kernel: Buffer I/O error on device hda, logical
block 67681
May 6 22:57:24 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:24 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:24 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:24 RBLR01 kernel: end_request: I/O error, dev hda, sector
270728
May 6 22:57:24 RBLR01 kernel: Buffer I/O error on device hda, logical
block 67682
May 6 22:57:29 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
Now, I am not left with any more solution I can think now. Please suggest.
On Wed, May 6, 2015 at 5:34 PM, Donald J. dona...@4email.net wrote:
The parameters would go in your vsftpd config file which is probably
in /etc or /etc/vsftpd. I no longer have a linux to look at to verify
that.
As I said, I don't think increasing timers from 60 or 300 is going to
fix your problem. 60 seconds is a long timer. You probably are
having a total hang at some point, so increasing a timer probably
won't help, but it won't hurt either.
You misunderstood what I said about netstat. Your want to do
netstat commands while your ftp is going so you can see the port
Re: SUSE FTP Server issue
On 5/7/2015 at 05:19 AM, Mainframe Mainframe mainframe1...@gmail.com
wrote:
Today I tried monitoring FTP server while running install script for z/VM
install and found interesting things.
So, while coping MAINT190 (190) DISK from DVD, we getting IO error.
-snip-
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:15 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): status=0x51 {
DriveReady SeekComplete Error }
May 6 22:57:15 RBLR01 kernel: hda: media error (bad sector): error=0x34
May 6 22:57:15 RBLR01 kernel: ide: failed opcode was 100
May 6 22:57:15 RBLR01 kernel: end_request: I/O error, dev hda, sector
270720
-snip-
I don't know what /dev/hda is on your computer. Since it's /dev/hda and not
/dev/hda1 I'm guessing it's a DVD reader. If that is the case, then creating a
new physical DVD might help. If it doesn't then the problem may be in the DVD
reader itself.
Now, I am not left with any more solution I can think now. Please suggest.
Hardly. You could do any of the following:
1. Upload the files from the DVD to z/VM and use the z/VM FTP server to provide
the files to the installation routine.
2. Insert the DVD into the HMC DVD reader and use the z/VM FTP server to
provide the files to the installation routine.
3. Replace the DVD drive on the PC.
4. Use another system that is running an FTP server. That might even be a z/OS
system.
Mark Post
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: SUSE FTP Server issue
Hello Donald,
Thanks for reply. I checked for my FTP server from
# netstat -antp |grep listen -i
tcp0 0 0.0.0.0:32769 0.0.0.0:* LISTEN
-
tcp0 0 0.0.0.0:20490.0.0.0:* LISTEN
-
tcp0 0 0.0.0.0:838 0.0.0.0:* LISTEN
4899/rpc.mountd
tcp0 0 0.0.0.0:15 0.0.0.0:* LISTEN
4994/xinetd
tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN
4233/portmap
tcp0 0 0.0.0.0:21 0.0.0.0:* LISTEN
4994/xinetd
tcp0 0 0.0.0.0:23 0.0.0.0:* LISTEN
4994/xinetd
tcp0 0 0.0.0.0:631 0.0.0.0:* LISTEN
4710/cupsd
tcp0 0 127.0.0.1:250.0.0.0:* LISTEN
4862/master
tcp0 0 0.0.0.0:667 0.0.0.0:* LISTEN
4726/ypbind
tcp0 0 :::22 :::*LISTEN
4362/sshd
So, in xinetd, we have
# cat /etc/xinetd.d/vsftpd
# default: off
# description:
# The vsftpd FTP server serves FTP connections. It uses
# normal, unencrypted usernames and passwords for authentication.
# vsftpd is designed to be secure.
service ftp
{
socket_type = stream
protocol= tcp
wait= no
user= root
server = /usr/sbin/vsftpd
#server_args =
#log_on_success += DURATION USERID
#log_on_failure += USERID
#nice= 10
}
Now, my query is do I need to add the parameter you mentioned in last
response in this vsftpd file.
accept_timeout
The timeout, in seconds, for a remote client to establish connection with a
PASV style data connection.
Default: 60
connect_timeout
The timeout, in seconds, for a remote client to respond to our PORT style
data connection.
Default: 60
data_connection_timeout
The timeout, in seconds, which is roughly the maximum time we permit data
transfers to stall for with no progress. If the timeout triggers, the
remote client is kicked off.
Default: 300
idle_session_timeout
The timeout, in seconds, which is the maximum time a remote client may
spend between FTP commands. If the timeout triggers, the remote client is
kicked off.
Default: 300
We contacted network team as well, But no solution till now. I am really
not able to find why FTP failing only while coping MNT190 disk.
IUGIDV8339I BYPASSING INSTDIR EXEC DUE TO PROGRAM RESTART
IUGILB8440I NOW LOADING MAINT190 (190) DISK 4 OF 317
IUGILB8344I FTPGET COMMAND FAILED FOR CKD190
REISSUING COMMAND.
CKD190*
DMSRXS1408W File TCPIP DATA * not found
PROCESSING CKD19000
IUGILB8342E THE COMMAND ' PIPE FTPGET CKD190* ' FAILED WITH RC= -111
IUGIDV8342E THE COMMAND ' EXEC INSTLBMD ' FAILED WITH RC= 100
IUGIDV8376E INSTDVD EXEC ENDED IN ERROR
IUGITL8342E THE COMMAND ' EXEC INSTDVD ' FAILED WITH RC=100
IUGITL8376E INSTALL EXEC ENDED IN ERROR. TO RESTART CORRECT THE PROBLEM AND
REIS
SUE INSTALL
Thanks for help.
On Thu, Apr 30, 2015 at 6:37 PM, Donald J. dona...@4email.net wrote:
Are these valid parms on your version of vsftpd?
But it is unlikely you would exceed 60 or 300 seconds.
accept_timeout
The timeout, in seconds, for a remote client to establish connection with
a PASV style data connection.
Default: 60
connect_timeout
The timeout, in seconds, for a remote client to respond to our PORT style
data connection.
Default: 60
data_connection_timeout
The timeout, in seconds, which is roughly the maximum time we permit data
transfers to stall for with no progress. If the timeout triggers, the
remote client is kicked off.
Default: 300
idle_session_timeout
The timeout, in seconds, which is the maximum time a remote client may
spend between FTP commands. If the timeout triggers, the remote client is
kicked off.
Default: 300
--
Donald J.
dona...@4email.net
we getting time out error but not sure about the reason.
We using SLES 9.2 with xinetd FTP server running under that. I checked
config file but I couldn't find any such parameter to increase session or
connection time out.
--
http://www.fastmail.com - Same, same, but different...
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
Re: SUSE FTP Server issue
The parameters would go in your vsftpd config file which is probably
in /etc or /etc/vsftpd. I no longer have a linux to look at to verify that.
As I said, I don't think increasing timers from 60 or 300 is going to
fix your problem. 60 seconds is a long timer. You probably are
having a total hang at some point, so increasing a timer probably
won't help, but it won't hurt either.
You misunderstood what I said about netstat. Your want to do
netstat commands while your ftp is going so you can see the port
numbers in the REMOTE column. NOTHING is happening at
the time you did the netstat below. Would be best to put the
netstat in a script and put a one second delay between commands.
Only reason for netstat is to see if you are hanging on one
particular remote port number. Your netstat below only shows
local port numbers because there are no remote connections
active at that time.
--
Donald J.
dona...@4email.net
On Wed, May 6, 2015, at 01:03 AM, Mainframe Mainframe wrote:
Hello Donald,
Thanks for reply. I checked for my FTP server from
# netstat -antp |grep listen -i
tcp0 0 0.0.0.0:32769 0.0.0.0:* LISTEN
-
tcp0 0 0.0.0.0:20490.0.0.0:* LISTEN
-
tcp0 0 0.0.0.0:838 0.0.0.0:* LISTEN
4899/rpc.mountd
tcp0 0 0.0.0.0:15 0.0.0.0:* LISTEN
4994/xinetd
tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN
4233/portmap
tcp0 0 0.0.0.0:21 0.0.0.0:* LISTEN
4994/xinetd
tcp0 0 0.0.0.0:23 0.0.0.0:* LISTEN
4994/xinetd
tcp0 0 0.0.0.0:631 0.0.0.0:* LISTEN
4710/cupsd
tcp0 0 127.0.0.1:250.0.0.0:* LISTEN
4862/master
tcp0 0 0.0.0.0:667 0.0.0.0:* LISTEN
4726/ypbind
tcp0 0 :::22 :::*LISTEN
4362/sshd
So, in xinetd, we have
# cat /etc/xinetd.d/vsftpd
# default: off
# description:
# The vsftpd FTP server serves FTP connections. It uses
# normal, unencrypted usernames and passwords for authentication.
# vsftpd is designed to be secure.
service ftp
{
socket_type = stream
protocol= tcp
wait= no
user= root
server = /usr/sbin/vsftpd
#server_args =
#log_on_success += DURATION USERID
#log_on_failure += USERID
#nice= 10
}
Now, my query is do I need to add the parameter you mentioned in last
response in this vsftpd file.
accept_timeout
The timeout, in seconds, for a remote client to establish connection with a
PASV style data connection.
Default: 60
connect_timeout
The timeout, in seconds, for a remote client to respond to our PORT style
data connection.
Default: 60
data_connection_timeout
The timeout, in seconds, which is roughly the maximum time we permit data
transfers to stall for with no progress. If the timeout triggers, the
remote client is kicked off.
Default: 300
idle_session_timeout
The timeout, in seconds, which is the maximum time a remote client may
spend between FTP commands. If the timeout triggers, the remote client is
kicked off.
Default: 300
We contacted network team as well, But no solution till now. I am really
not able to find why FTP failing only while coping MNT190 disk.
IUGIDV8339I BYPASSING INSTDIR EXEC DUE TO PROGRAM RESTART
IUGILB8440I NOW LOADING MAINT190 (190) DISK 4 OF 317
IUGILB8344I FTPGET COMMAND FAILED FOR CKD190
REISSUING COMMAND.
CKD190*
DMSRXS1408W File TCPIP DATA * not found
PROCESSING CKD19000
IUGILB8342E THE COMMAND ' PIPE FTPGET CKD190* ' FAILED WITH RC= -111
IUGIDV8342E THE COMMAND ' EXEC INSTLBMD ' FAILED WITH RC= 100
IUGIDV8376E INSTDVD EXEC ENDED IN ERROR
IUGITL8342E THE COMMAND ' EXEC INSTDVD ' FAILED WITH RC=100
IUGITL8376E INSTALL EXEC ENDED IN ERROR. TO RESTART CORRECT THE PROBLEM AND
REIS
SUE INSTALL
Thanks for help.
On Thu, Apr 30, 2015 at 6:37 PM, Donald J. dona...@4email.net wrote:
Are these valid parms on your version of vsftpd?
But it is unlikely you would exceed 60 or 300 seconds.
accept_timeout
The timeout, in seconds, for a remote client to establish connection with
a PASV style data connection.
Default: 60
connect_timeout
The timeout, in seconds, for a remote client to respond to our PORT style
data connection.
Default: 60
data_connection_timeout
The timeout, in seconds, which is roughly the maximum time we permit data
transfers to stall for with no progress. If the timeout triggers, the
remote client is kicked off.
Default: 300
Re: SUSE FTP Server issue
On Wednesday, 05/06/2015 at 04:05 EDT, Mainframe Mainframe mainframe1...@gmail.com wrote: We contacted network team as well, But no solution till now. I am really not able to find why FTP failing only while coping MNT190 disk. That's nonsense, Mainframe Mainframe. They found *something*. Either the tcp window closed all the way (to zero) and FTPGET couldn't persuade it to re-open, or vsftpd stopped transmitting *all* data. Either of those results is useful information. At the very least could at least have run tcpdump on your ftp server. IUGIDV8339I BYPASSING INSTDIR EXEC DUE TO PROGRAM RESTART IUGILB8440I NOW LOADING MAINT190 (190) DISK 4 OF 317 IUGILB8344I FTPGET COMMAND FAILED FOR CKD190 REISSUING COMMAND. CKD190* DMSRXS1408W File TCPIP DATA * not found PROCESSING CKD19000 IUGILB8342E THE COMMAND ' PIPE FTPGET CKD190* ' FAILED WITH RC= -111 IUGIDV8342E THE COMMAND ' EXEC INSTLBMD ' FAILED WITH RC= 100 IUGIDV8376E INSTDVD EXEC ENDED IN ERROR IUGITL8342E THE COMMAND ' EXEC INSTDVD ' FAILED WITH RC=100 IUGITL8376E INSTALL EXEC ENDED IN ERROR. TO RESTART CORRECT THE PROBLEM AND REIS SUE INSTALL If that's all the messages you got, then you have a worse problem. Whenever FTPGET gives RC= -111, it always issues a message. Always. But I don't see it. Double check your vsftpd logs (and /var/log/messages) to see if the server issued any messages or Linux issued any messages about vsftpd. But no one can tell you how to solve the problem since we don't know what's causing it. We can *guess*, but you can do that on your own. To get our help, you need to supply us with information. Get the tcpdump packet trace from your Linux server, run it through wireshark and see what's happening. If you don't know how to do that, you need to learn, and here's your opportunity. Everyone in this business needs to learn something about how TCP/IP works. When I teach at conferences or am speaking to a client, I ask How many of you here are network engineers? A hand or two will go up. My response: No, all of you are. And this is why. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SUSE FTP Server issue
For giggles you might try running your FTP as a listen server instead of
being started by xinetd.
listen=YES
On Wed, May 6, 2015 at 8:04 AM, Donald J. dona...@4email.net wrote:
The parameters would go in your vsftpd config file which is probably
in /etc or /etc/vsftpd. I no longer have a linux to look at to verify
that.
As I said, I don't think increasing timers from 60 or 300 is going to
fix your problem. 60 seconds is a long timer. You probably are
having a total hang at some point, so increasing a timer probably
won't help, but it won't hurt either.
You misunderstood what I said about netstat. Your want to do
netstat commands while your ftp is going so you can see the port
numbers in the REMOTE column. NOTHING is happening at
the time you did the netstat below. Would be best to put the
netstat in a script and put a one second delay between commands.
Only reason for netstat is to see if you are hanging on one
particular remote port number. Your netstat below only shows
local port numbers because there are no remote connections
active at that time.
--
Donald J.
dona...@4email.net
On Wed, May 6, 2015, at 01:03 AM, Mainframe Mainframe wrote:
Hello Donald,
Thanks for reply. I checked for my FTP server from
# netstat -antp |grep listen -i
tcp0 0 0.0.0.0:32769 0.0.0.0:*
LISTEN
-
tcp0 0 0.0.0.0:20490.0.0.0:*
LISTEN
-
tcp0 0 0.0.0.0:838 0.0.0.0:*
LISTEN
4899/rpc.mountd
tcp0 0 0.0.0.0:15 0.0.0.0:*
LISTEN
4994/xinetd
tcp0 0 0.0.0.0:111 0.0.0.0:*
LISTEN
4233/portmap
tcp0 0 0.0.0.0:21 0.0.0.0:*
LISTEN
4994/xinetd
tcp0 0 0.0.0.0:23 0.0.0.0:*
LISTEN
4994/xinetd
tcp0 0 0.0.0.0:631 0.0.0.0:*
LISTEN
4710/cupsd
tcp0 0 127.0.0.1:250.0.0.0:*
LISTEN
4862/master
tcp0 0 0.0.0.0:667 0.0.0.0:*
LISTEN
4726/ypbind
tcp0 0 :::22 :::*
LISTEN
4362/sshd
So, in xinetd, we have
# cat /etc/xinetd.d/vsftpd
# default: off
# description:
# The vsftpd FTP server serves FTP connections. It uses
# normal, unencrypted usernames and passwords for authentication.
# vsftpd is designed to be secure.
service ftp
{
socket_type = stream
protocol= tcp
wait= no
user= root
server = /usr/sbin/vsftpd
#server_args =
#log_on_success += DURATION USERID
#log_on_failure += USERID
#nice= 10
}
Now, my query is do I need to add the parameter you mentioned in last
response in this vsftpd file.
accept_timeout
The timeout, in seconds, for a remote client to establish connection
with a
PASV style data connection.
Default: 60
connect_timeout
The timeout, in seconds, for a remote client to respond to our PORT style
data connection.
Default: 60
data_connection_timeout
The timeout, in seconds, which is roughly the maximum time we permit data
transfers to stall for with no progress. If the timeout triggers, the
remote client is kicked off.
Default: 300
idle_session_timeout
The timeout, in seconds, which is the maximum time a remote client may
spend between FTP commands. If the timeout triggers, the remote client is
kicked off.
Default: 300
We contacted network team as well, But no solution till now. I am really
not able to find why FTP failing only while coping MNT190 disk.
IUGIDV8339I BYPASSING INSTDIR EXEC DUE TO PROGRAM RESTART
IUGILB8440I NOW LOADING MAINT190 (190) DISK 4 OF 317
IUGILB8344I FTPGET COMMAND FAILED FOR CKD190
REISSUING COMMAND.
CKD190*
DMSRXS1408W File TCPIP DATA * not found
PROCESSING CKD19000
IUGILB8342E THE COMMAND ' PIPE FTPGET CKD190* ' FAILED WITH RC= -111
IUGIDV8342E THE COMMAND ' EXEC INSTLBMD ' FAILED WITH RC= 100
IUGIDV8376E INSTDVD EXEC ENDED IN ERROR
IUGITL8342E THE COMMAND ' EXEC INSTDVD ' FAILED WITH RC=100
IUGITL8376E INSTALL EXEC ENDED IN ERROR. TO RESTART CORRECT THE PROBLEM
AND
REIS
SUE INSTALL
Thanks for help.
On Thu, Apr 30, 2015 at 6:37 PM, Donald J. dona...@4email.net wrote:
Are these valid parms on your version of vsftpd?
But it is unlikely you would exceed 60 or 300 seconds.
accept_timeout
The timeout, in seconds, for a remote client to establish connection
with
a PASV style data connection.
Default: 60
connect_timeout
The timeout, in seconds, for a remote client to respond to our PORT
style
data connection.
Default: 60
data_connection_timeout
The timeout,
Re: SUSE FTP Server issue
Are these valid parms on your version of vsftpd? But it is unlikely you would exceed 60 or 300 seconds. accept_timeout The timeout, in seconds, for a remote client to establish connection with a PASV style data connection. Default: 60 connect_timeout The timeout, in seconds, for a remote client to respond to our PORT style data connection. Default: 60 data_connection_timeout The timeout, in seconds, which is roughly the maximum time we permit data transfers to stall for with no progress. If the timeout triggers, the remote client is kicked off. Default: 300 idle_session_timeout The timeout, in seconds, which is the maximum time a remote client may spend between FTP commands. If the timeout triggers, the remote client is kicked off. Default: 300 -- Donald J. dona...@4email.net we getting time out error but not sure about the reason. We using SLES 9.2 with xinetd FTP server running under that. I checked config file but I couldn't find any such parameter to increase session or connection time out. -- http://www.fastmail.com - Same, same, but different... -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SUSE FTP Server issue
You might also write a small script that redirects netstat -an file.log every 1 second or so to see what remote port number you continually fail on. Then check the firewall, iptables, passive port range, etc in regards to that port number. -- Donald J. dona...@4email.net we getting time out error but not sure about the reason. We using SLES 9.2 with xinetd FTP server running under that. I checked config file but I couldn't find any such parameter to increase session or connection time out. Please suggest. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- http://www.fastmail.com - Choose from over 50 domains or use your own -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SUSE FTP Server issue
Yes, we are handling network as well and we don't find any issues. We tried manually connecting to FTP server from windows machine and transferred data and all worked fine . But not sure, If we have to make any changes in FTP server config file for session related parameter. On Thu, Apr 30, 2015 at 10:39 AM, Mark Post mp...@suse.com wrote: On 4/30/2015 at 12:44 AM, Mainframe Mainframe mainframe1...@gmail.com wrote: Hello All, We are installing z/VM 6.3 using FTP server. After running install script , is getting failed while NOW LOADING MAINT190 (190) DISK 4 OF 317 -snip- we getting time out error but not sure about the reason. -snip- Please suggest. For a couple of days now, Alan Altmark has been suggesting you work with your network team to figure this out. Have you done that? Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SUSE FTP Server issue
On 4/30/2015 at 01:27 AM, Mainframe Mainframe mainframe1...@gmail.com wrote: Yes, we are handling network as well and we don't find any issues. We tried Does that mean they ran a network trace while reproducing the problem? If not, they should. manually connecting to FTP server from windows machine and transferred data and all worked fine . But not sure, If we have to make any changes in FTP server config file for session related parameter. There is probably no FTP-related parameter for that. I suspect the problem is not in the FTP server but some firewall or router in between. Again, network traces will help figure that out. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SUSE FTP Server issue
It firewall is the issue then system should not copied first 3 disks. If you look at the error, we getting error only after 3rd disk copy. IUGILB8440I NOW LOADING MAINTCF1 (CF1) DISK 1 OF 317 IUGILB8440I NOW LOADING MAINTCFD (CFD) DISK 2 OF 317 IUGILB8440I NOW LOADING MAINTCF3 (CF3) DISK 3 OF 317 IUGILB8440I NOW LOADING MAINT190 (190) DISK 4 OF 317 IUGILB8344I FTPGET COMMAND FAILED FOR CKD190 REISSUING COMMAND. CKD190* DMSRXS1408W File TCPIP DATA * not found PROCESSING CKD19000 FTPGET TIMED OUT READING FROM STREAM, REPLY=0 0 READ WRITE EXCEPTION. FTPGET FAILED WITH RC=-111 On Thu, Apr 30, 2015 at 11:02 AM, Mark Post mp...@suse.com wrote: On 4/30/2015 at 01:27 AM, Mainframe Mainframe mainframe1...@gmail.com wrote: Yes, we are handling network as well and we don't find any issues. We tried Does that mean they ran a network trace while reproducing the problem? If not, they should. manually connecting to FTP server from windows machine and transferred data and all worked fine . But not sure, If we have to make any changes in FTP server config file for session related parameter. There is probably no FTP-related parameter for that. I suspect the problem is not in the FTP server but some firewall or router in between. Again, network traces will help figure that out. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SUSE FTP Server issue
On 4/30/2015 at 01:36 AM, Mainframe Mainframe mainframe1...@gmail.com wrote: It firewall is the issue then system should not copied first 3 disks. If you look at the error, we getting error only after 3rd disk copy. Neither Alan nor I are saying it's a problem with firewall _rules_. Rather something to do with timeouts, traffic, etc. You really need to ask to have network traces performed. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SUSE FTP Server issue
On 4/30/2015 at 12:44 AM, Mainframe Mainframe mainframe1...@gmail.com wrote: Hello All, We are installing z/VM 6.3 using FTP server. After running install script , is getting failed while NOW LOADING MAINT190 (190) DISK 4 OF 317 -snip- we getting time out error but not sure about the reason. -snip- Please suggest. For a couple of days now, Alan Altmark has been suggesting you work with your network team to figure this out. Have you done that? Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
