Sponsored Content
Special Forums Cybersecurity Datacenter Crash (Server Unreachable for About 17 minutes) Post 303044539 by Neo on Tuesday 25th of February 2020 06:17:00 PM
Old 02-25-2020
Both outages have been due to networking issues in the datacenter. The dedicated server itself has been fine (I did reboot it once when the network was down).

I have all the details of the server of course but the server is not the problem. The datacenter is the problem.

They did contact me from billing and offer to waive the fees next month for two servers; but I have not responded yet.

After two outages in a single 24 hour period my "anger meter" went up dramatically and I am letting it go back down again before I reply back to them.
These 2 Users Gave Thanks to Neo For This Post:
 

10 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

linux server crash

Hi I faced a problem while booting linux which is as follows;- ************************************************* Inode 146180 has illegal block(s) xauth:error in locking authority file /home/root/.Xauthority Fatal Server Error: Could not create lock file in /tmp/tXo-lock ... (1 Reply)
Discussion started by: Abhishek
1 Replies

2. UNIX for Dummies Questions & Answers

server crash

Our SUn Solaris Server has crashed second time in 2 days, reason is not known , we are trying to determine what could have gone wrong, any ideas, the power supply seems to be fine, there is no response from keyboard,monitor etc and we had to do a hot boot yesterday.. Any suggestions what could be... (9 Replies)
Discussion started by: knarayan
9 Replies

3. UNIX for Advanced & Expert Users

Solaris Server Crash

We have had a server (Solaris 2.6) hardisk crash. When booting the server we get: ok> boot -S Boot Device: /sbus/espdmc@e, 8400000/esp@e,8800000/sd@0,0 short read 0x2000 chars read disk read error The only way we can get into the console is to ok> boot cdrom whereby everything (e.g.... (3 Replies)
Discussion started by: Breen
3 Replies

4. UNIX for Dummies Questions & Answers

Notification if server unreachable?

Is it possible for a group of servers to monitor each other and then send an alert if one of them is no longer 'alive'? Or if its easier have one server that monitors the other five and then sends an alert. If so how would this be done? Thanks (3 Replies)
Discussion started by: Sepia
3 Replies

5. Linux

crash dump server for red hat ent 4

Is it true that you can't have the crash dump server/client on the same server? I know I've installed Nagios open source before, I though it's only for that kind of thing. I never though that Red hat ent 4 would be like client/server on the crash dump. if someone is having problem with high... (0 Replies)
Discussion started by: itik
0 Replies

6. Programming

Client/Server Socket Application - Preventing Client from quitting on server crash

Problem - Linux Client/Server Socket Application: Preventing Client from quitting on server crash Hi, I am writing a Linux socket Server and Client using TCP protocol on Ubuntu 9.04 x64. I am having problem trying to implement a scenario where the client should keep running even when the... (2 Replies)
Discussion started by: varun.nagpaal
2 Replies

7. SCO

Crash error on my unix server

Hi there. Well i have a really bad problem with my server: UnixWare Version 5 Release 7 The system crash :wall: and show the error: Panic: Kernel-mode address fault on user address 0x00000004 :eek: If anyone knows about the reason of this error please give me a help Sorry by my english.... (3 Replies)
Discussion started by: danilosevilla
3 Replies

8. Programming

Client accidently close when the server crash

The steps to test the problem 1. Open TCP Server 2. Open TCP Client 3. TCP Client sends data to Server. 4. Close TCP Server and the client also crash without any notification Second wonderful test: 1. Comment the following statement in Client.c (at line 168) and compile it Writen(... (1 Reply)
Discussion started by: sehang
1 Replies

9. Red Hat

how to configure netdump to copy the crash in the server itself??

hi, i would like to configure netdump, but saving the var/crash in the server itself, not in another server. could anybody tell me if this is possible? thanks (4 Replies)
Discussion started by: pabloli150
4 Replies

10. AIX

System p 9115-505: Server and HMC unreachable

Hi there I've bought a used System p 9115-505. When I attach the LAN cable to my router the HMC receives an IP address from my router, but the HMC is unreachable. There are no open ports. Does anybody know that problem? Any help greatly appreciated. Greetings from Italy! (2 Replies)
Discussion started by: mediaset23
2 Replies
YPXFR(8)						    BSD System Manager's Manual 						  YPXFR(8)

NAME
ypxfr -- transfer NIS database from remote server to local host SYNOPSIS
/usr/libexec/ypxfr [-f] [-c] [-d target domain] [-h source host] [-s source domain] [-p path] [-C taskid program-number ipaddr port] mapname DESCRIPTION
The ypxfr utility copies an NIS database (or map) from one NIS server to another using NIS services. In FreeBSD, ypxfr is generally invoked by ypserv(8) when it receives a map transfer request from yppush(8). The ypxfr utility is used primarily in environments where several NIS servers are in use in a single domain. One server, the NIS master, maintains the canonical copies of all NIS maps, and all the other servers, the NIS slaves, copy new versions of the maps from the master whenever any updates are made (i.e., when a user updates their pass- word via yppasswd(1)). When run, ypxfr creates a temporary database file in /var/yp/[domainname], and fills it with the contents of mapname as supplied by the spec- ified source host. When the entire map has been transferred, ypxfr deletes the original copy of mapname and moves the temporary copy into its place. When the transfer is complete, ypxfr will attempt to send a 'clear current map' request to the local ypserv(8) process to clear any possible references it may still have to the stale map. Note that all files created by ypxfr are owner readable and writable only for security reasons. Since the NIS maps and the directory in which they reside are normally owned by root, this prevents non-privileged users from making unauthorized modifications. In order to maintain consistency across all NIS servers, ypxfr can be run periodically in a cron(8) job. Maps which change infrequently need only be updated once a day (preferably late at night when system usage is lowest), whereas those that are subject to frequent changes (such a passwd.byname and passwd.byuid) should be updated perhaps once every hour. Using cron(8) to automatically update the NIS maps is not strictly mandatory since all updates should be propagated by yppush(8) when /var/yp/Makefile is run on the NIS master server, however it is good practice on large networks where possible outages could cause NIS servers to fall out of sync with each other. When ypxfr is invoked without a controlling terminal, e.g. from inside ypserv(8), it logs all its output using the syslog(3) facility. NOTES
The FreeBSD version of ypxfr has support for a special map transfer protocol which works in conjunction with the FreeBSD rpc.ypxfrd(8) server. This protocol allows it to transfer raw map database files from the NIS master server and can be many times faster than the standard transfer method, particularly for very large NIS maps. The ypxfr utility will check to see if the rpc.ypxfrd(8) server is registered on the NIS master server and attempt to use it if it is present. If it is not it will fall back to the standard transfer method, copying the map contents from ypserv(8) and creating new maps instead. Note that while the FreeBSD ypxfrd protocol is conceptually similar to the SunOS ypxfrd protocol, the FreeBSD protocol is not compatible with Sun's, therefore it will not work with Sun's ypxfrd server. FreeBSD slave systems can still transfer maps from any non-FreeBSD NIS server, however they will only be able to take advantage of the faster protocol if the master server is also running FreeBSD. OPTIONS
The following options and flags are supported by ypxfr: -f Force a map transfer. Normally, ypxfr will not transfer a map if it determines that the NIS master's copy is not newer than the existing copy already on the local host: the -f flag forces a transfer regardless of which server's version is more recent. -c Do not send a 'clear current map' request to the ypserv(8) process running on the local host. This flag is normally used when invok- ing ypxfr manually on a machine that is not yet running ypserv(8). Without this flag, failure to contact the local NIS server will cause ypxfr to abort the transfer. -d target domain Specify a target domain other than the current NIS domain. -h source host Specify the name of the host from which to copy the NIS maps. This option is used to ensure that ypxfr only copies maps from the NIS master server. -s source domain Specify the domain from which to transfer a map, in the event that the transfer is being done across two different NIS domains. -p path Specify the top level directory containing the NIS maps. By default, this path is /var/yp. The -p flag allows you to specify an alternate path should you wish to store your NIS maps in a different part of the file system. The NIS server, ypserv(8), passes this flag to ypxfr if it too has been told to use an alternate path. -C taskid program-number ipaddr port These options are used only when ypxfr is invoked by ypserv(8) in response to a map transfer request initiated by yppush(8). In this instance, ypxfr needs to 'callback' to the yppush(8) process and interact with it, so yppush(8) passes to it an IP address ipaddr, port number port, registered program number program-number and a transaction ID taskid that it can use to contact the waiting yppush(8) process on the master server. mapname The name of the map to transfer. FILES
/var/yp/[domainname]/[maps] The NIS maps for a particular NIS domain. SEE ALSO
yp(8), yppush(8), ypserv(8) AUTHORS
Bill Paul <wpaul@ctr.columbia.edu> BSD
February 5, 1995 BSD
All times are GMT -4. The time now is 08:40 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy