search for: l1930

...this line? > > https://github.com/networkupstools/nut/blob/master/clients/upsmon.c#L1923 The kill error is coming from this line: https://github.com/networkupstools/nut/blob/master/common/common.c#L263 Which is called from: https://github.com/networkupstools/nut/blob/master/client/upsmon.c#L1930 In which case would you need to "see if this is going to work first"? > >> If this is normal operation, maybe they shouldn't be printed to the console? > > Agreed. It would probably involve adding another parameter to the sendsignal() calls, indicating whether the kil...

On Aug 1, 2013, at 1:34 AM, Kris Jordan wrote: > The kill error is coming from this line: > https://github.com/networkupstools/nut/blob/master/common/common.c#L263 > > Which is called from: > https://github.com/networkupstools/nut/blob/master/client/upsmon.c#L1930 > > In which case would you need to "see if this is going to work first"? Agreed, the first kill(pid, 0) is redundant in that case. https://github.com/networkupstools/nut/blob/master/clients/upsmon.c#L1930 -- Charles Lepple clepple at gmail

On Jul 30, 2013, at 1:36 PM, Kris Jordan wrote: > upsd removes its pid files when it's stopped, upsmon does not. Hmm, interesting observation. Offhand, I think both should remove the PID files, but the way that upsmon drops root privileges might make this difficult. > If I remove upsmon's manually after stopping it, I get a different message for it when I start it back up... >

Centos5 NUT 2.6.5, compiled from source I was reminded by a previous thread about a message I get when starting NUT... Starting upsd: fopen /var/run/nut/upsd.pid: No such file or directory Starting upsmon: kill: No such process upsd removes its pid files when it's stopped, upsmon does not. If I remove upsmon's manually after stopping it, I get a different message for it when I start

...to not care too much about having large core files written to it. Ideally we would have liked to use a special capture disk, but it turns out that the kernel contains code which disallows using a /dev device (or any non-regular file) for coredumps: http://lxr.linux.no/linux+v2.6.34.1/fs/exec.c#L1930 We could do it using a coredump-to-pipe, but I think it would be better to just remove this limitation in the kernel. Another shortcoming is that a coredump isn't a stack trace, and to get a stack trace you really need a copy of the daemon around with debugging enabled. It is possible we cou...