similar to: C7, nfs issue on restart

On Thu, 18 Feb 2016, m.roth at 5-cent.us wrote: > This is happening on anything other than plain vanilla Dell servers. One > R730, with dual Tesla cards, one R420, with a fibre card for a RAID > device, it never switches root. All these systems have Xeons, not AMD > CPUs. > > We've had this with every one of the 327 kernels. In addition, it seems to > happen also with the

This is happening on anything other than plain vanilla Dell servers. One R730, with dual Tesla cards, one R420, with a fibre card for a RAID device, it never switches root. All these systems have Xeons, not AMD CPUs. We've had this with every one of the 327 kernels. In addition, it seems to happen also with the 229.20.1; the 229.14.1 has no such problem. >From the rdsosreport: starting

Paul Heinlein wrote: > On Thu, 18 Feb 2016, m.roth at 5-cent.us wrote: > >> This is happening on anything other than plain vanilla Dell servers. One >> R730, with dual Tesla cards, one R420, with a fibre card for a RAID >> device, it never switches root. All these systems have Xeons, not AMD >> CPUs. >> >> We've had this with every one of the 327

Ok, folks, I don't get this one at all. I've got a server that I just rebuilt last week, from C5 to C7. It used to export filesystems. Those were moved to another server, and NFS wasn't turned up when I built it. I just turned it down again. And yet, I see Mar 14 10:26:33 <servername> systemd: Job dev-disk-by\x2dlabel-export1.device/start timed out. Mar 14 10:26:33

I am trying to get a remote screen on C7. I did the following on C7 server: yum install tigervnc-server cp /lib/systemd/system/vncserver at .service /etc/systemd/system/vncserver@:1.service systemctl daemon-reload edit /etc/systemd/system/vncserver@:1.service and replace <USER> with myuser su - myuser run

On Thu, Jun 2, 2016 at 7:56 AM, Jerry Geis <geisj at pagestation.com> wrote: > I am trying to get a remote screen on C7. > I did the following on C7 server: > yum install tigervnc-server > cp /lib/systemd/system/vncserver at .service > /etc/systemd/system/vncserver@:1.service > systemctl daemon-reload > edit

------------ Original Message ------------ > Date: Sunday, May 10, 2015 01:20:34 PM -0700 > From: John R Pierce <pierce at hogranch.com> > > On 5/10/2015 1:04 PM, Earl A Ramirez wrote: >> Did a little Googling [0] and I saw that they recommend starting >> it as follows: >> >> /etc/init.d/mysql start > > which is old school sysVinit style. >

On 11/23/2014 12:02 PM, Edward M wrote: > > On 11/23/2014 10:58 AM, Gregory P. Ennis wrote: >> Everyone, >> >> I have installed Centos 7.0 on my homework machine in order to take a >> test drive with it, and am low on the learning curve with it at this >> point. I have a small Gateway SX2855-UB12P. >> >> I have a critical hurdle in that when I try

Thats wierd. I've never had any problem with systemctl or systemd like that. Do you have your service file in the right place with the right permissions. here is the httpd service file as a reference. [centos at ipa ~]$ ls /usr/lib/systemd/system/httpd.service -l -rw-r--r--. 1 root root 694 Mar 12 14:57 /usr/lib/systemd/system/httpd.service [centos at ipa ~]$ cat

On Tue, 14 Mar 2017, m.roth at 5-cent.us wrote: > Ok, folks, I don't get this one at all. > > I've got a server that I just rebuilt last week, from C5 to C7. It used to > export filesystems. Those were moved to another server, and NFS wasn't > turned up when I built it. I just turned it down again. And yet, I see > Mar 14 10:26:33 <servername> systemd: Job >

On Sun, Sep 30, 2018 at 08:56:52PM +0200, Alessandro Baggi wrote: > Hi James, > I tried as suggested installing cuda but the problem persist. > In a previous c7.5 installation all works as expected but the driver was > less then 390.77. I'm puzzled... I'm running up to date C7 with Nvidia card and the elrepo nvidia bits at 390.87 without problems. Have you tried using the

On 19.01.24 09:00, Jim Klimov via Nut-upsuser wrote: >Well, from your logs it seems that at 05:17:03 your nut-server (upsd) >restarted, so an upsmon reconnection attempt at 05:17:09 had an issue with >that (config not all applied? strange a bit) but since 05:17:14 it is okay. > >Maybe a few too many banners shown from upsmon, while its same uptime seems >to continue. Maybe

Jan 19 05:50:13 mars nut-monitor[849]: Signal 15: exiting Jan 19 05:50:13 mars nut-monitor[849]: Network UPS Tools upsmon 2.8.0 Jan 19 05:50:13 mars systemd[1]: Stopping nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller... Jan 19 05:50:13 mars systemd[1]: nut-monitor.service: Deactivated successfully. Jan 19 05:50:13 mars systemd[1]: Stopped nut-monitor.service

Hello and thanks for all the replies. This morning at 9:50 the server stopped working unexpectedly - I was still sleeping until 10:00, so no user intervention took place. Jan 19 05:50:17 mars nut-server[1303]: mainloop: Interrupted system call Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exiting Jan 19 05:50:17 mars nut-server[1303]: Network UPS Tools upsd 2.8.0 Jan 19 05:50:17 mars

On Wed, Aug 23, 2017 at 12:03:12PM -0700, Gordon Messmer wrote: > On 08/21/2017 07:23 PM, Fred Smith wrote: > >so, in my case, the USB drive contains an xfs filesystem. would I > >do something like this: > > > >in /etc/auto.master: > >backup /etc/auto.backup > > > >and in /etc/auto.backup > >backup -fstype=xfs,defaults,noauto,users

On 19.01.24 16:20, Stefan Schumacher via Nut-upsuser wrote: >This morning at 9:50 the server stopped working unexpectedly - I was >still sleeping until 10:00, so no user intervention took place. > >Jan 19 05:50:17 mars nut-server[1303]: mainloop: Interrupted system call >Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exiting >Jan 19 05:50:17 mars nut-server[1303]: Network UPS

With recent NUT releases, driver disconnections should be contained in its own `nut-driver at eaton` instance (the `@upsname` part is derived from the `ups.conf` section name). One of the drivers failing and restarting is not a proper cause for the data server to recycle. Also, nowadays some (maybe not all) USB-capable drivers should try to reconnect without restarting. Note however, that in some

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yet more information: As a test I moved the link /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service into /etc/systemd/user and reran systemctl daemon-reload. I then rebooted. # ls -l /etc/systemd/user total 4 lrwxrwxrwx. 1 root root 41 Jul 27 2014 dbus-org.fedoraproject.FirewallD1.service ->

That is the thing - rpc.statd does have rpcbind a pre-req. It looks like systemd is not handling this correctly. Just wondering if anyone knows a good way to fix. root at ls2 /usr/lib/systemd/system 110# grep Requires rpc-statd.service Requires=nss-lookup.target rpcbind.target On 8/30/15 7:45 PM, Rob Kampen wrote: > On 08/31/2015 01:39 PM, Mark Selby wrote: >> I have seen some talk

On 08/31/2015 01:39 PM, Mark Selby wrote: > I have seen some talk about this but have not seen any answers. I know > this is a problem on CentOS 7.1 and I also think it is a problem on > CentOS 7.0. > > Basically if I have an NFS client only config - meaning that the > nfs-server.service is not enabled then I have to wait 60 seconds after > boot for the 1st NFSV3 mount to