search for: statepath

...lly about nut, and the second group setting state, pid, altpid: --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --with-statepath=PATH path for ups state files (${STATEPATH}, typically /var/state/ups) --with-altpidpath=PATH path for NUT driver/upsd .pid files not running as root (<statepath>) --with-pidpath=PATH Path for root-owned .pid files (${PIDPATH},...

...bring down or otherwise confuse the OS). As such, daemons that start as not-root or drop privileges early can not create their PID or socket files there. * The ALTPIDPATH as commented is for PIDs of non-root daemons (since recently it is also checked for root daemons as a fallback, I think). * The STATEPATH is a historic misnomer: a long time ago drivers wrote their state regularly into a dedicated file which upsd then had regularly read to post data updates. This was later changed to local sockets, but the name stuck. I don't think there's anything currently that needs to be persisted there o...

This morning I finished building and configuring nut 2.6.0 on OpenBSD 4.8, and it is running fine. While I was in the config files, I noticed what looks like it may be a discrepancy between the config file commetns and the configure script default. uspd.conf has the following comment: # STATEPATH <path> # STATEPATH /var/run/nut # # Tell upsd to look for the driver state sockets in 'path' rather # than the default that was compiled into the program. When I read that, I thought the default path compiled into the program would be /var/run/nut However, configure --help shows...

> Also the upsmon POWERDOWNFLAG fits into this question I'm confused. That flag can't be persistent across reboots, can it?

I had read the "Also the upsmon POWERDOWNFLAG fits into this question" in your response as you meant the flag belonged in the persistent state directory.

Edgar Fu? via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes: > I had read the "Also the upsmon POWERDOWNFLAG fits into this question" > in your response as you meant the flag belonged in the persistent > state directory. I didn't 100% follow what Jim thinks. I think it belongs in /var/run-ish-root.

...H Changes the directory where pid files are stored. By default this is /var/run. Certain programs like upsmon will leave files here. --with-altpidpath=PATH Programs that normally don't have root powers, like the drivers and upsd, write their pid files here. By default this is whatever the statepath is, as those programs should be able to write there. --with-statepath=PATH Change the default location of the state sockets created by the drivers. The NUT_STATEPATH environment variable overrides this at run time. Default is /var/state/ups. ----------------------------------- So, the PID pat...

>> Also the upsmon POWERDOWNFLAG fits into this question > I'm confused. That flag can't be persistent across reboots, can it? Well, there is little practical reason, if any, for an `/etc/killpower` (as it is commonly named) to exist when you boot. It also has a potential for confusion if not deleted, as we discovered in some recent discussion - e.g. due to no packaged NUT init

I am running tests on my system and UPS, making sure that it is reliably able to come up, detect power loss, shutdown safely, and then come back up when the power returns. It does that MOST of the time. However, a significant part of the time, the system comes up, and then doesn't respond to loss of power. Doing some checking, I find that the reason is because upsd never started. Capturing

...From the FreeBSD ports tree: /usr/ports/sysutils/nut/Makefile: STATEDIR?= /var/db/nut [...] CONFIGURE_ARGS= --sysconfdir=${PREFIX}/etc/nut \ --program-transform-name="" \ --localstatedir=${STATEDIR} \ --datadir=${PREFIX}/etc/nut \ --with-drvpath=${PREFIX}/libexec/nut \ --with-statepath=${STATEDIR} \ --with-altpidpath=${STATEDIR} \ --with-pidpath=${STATEDIR} \ --with-pkgconfig-dir=${PREFIX}/libdata/pkgconfig \ --with-user=${NUT_USER} \ --with-group=${NUT_GROUP} \ --with-dev I think you need to re-run ./configure in the source tree with the driver, using the arguments...

...e first, or use the 'reload' command. What might be happening is that the PID file is left over from the last test, and another process got that PID instead. Due to history and conflicting requirements, the path selection is not as simple as it could be. From ./configure --help: --with-statepath=PATH path for ups state files (/var/state/ups) --with-altpidpath=PATH path for driver/upsd .pid files (<statepath>) [...] --with-pidpath=PATH path for .pid files (/var/run) You might not want to use the default for --with-altpidpath: /var/state/* is not generally cleared at boot t...

...th is allocating memory with xstrdup. Doesn't this line produce a memory leak ? > #endif > - } > - > - return path; > + return (path != NULL) ? path : CONFPATH; > } > > /* Return the default path for the directory containing state files */ > -const char * dflt_statepath(void) > +const char * dflt_statepath(void) > { > - const char * path; > - > - if ((path = getenv("NUT_STATEPATH")) == NULL) { > #ifndef WIN32 > - path = STATEPATH; > + const char *path = getenv("NUT_STATEPATH"); > #else > - if( relative_state_...

...If we ever want to autodetect (by whatever means) what drivers are started (udev?) and we start them automatically, this probably means these drivers will not be configured in 'ups.conf' either and won't be seen. What we could also do, is to let the server checkout the contents of the STATEPATH and contact to all sockets it finds there. This would also do away with the necessity to keep the socketnames in the drivers and the server in sync. There are two caveats though: 1) Drivers must have created their socket before the server is started. This is not different from what we have now, bu...

I'm trying to see if we can make upsd autodetect the driver sockets from the STATEPATH. This works quite well and uses surprisingly little code (much less than parsing the 'ups.conf' file). However, since I can no longer read the name from the 'ups.conf' file, I need to extract this from the name of the socket. We might simply strip the drivername from the socket name...

...pool and /var/mail can grow and potentially consume the entire volume. Looking at the source code for drivers/main.c I observe that the chdir is happening in main() on line 551. The call to shutdown the UPS happens a few lines later, on line 568. The interesting lines are: if (chdir(dflt_statepath())) fatal("Can't chdir to %s", dflt_statepath()); setup_signals(); /* clear out callback handler data */ memset(&upsh, '\0', sizeof(upsh)); upsdrv_initups(); /* now see if things are very wrong out there */...

# reboot Connection to 192.168.5.81 closed by remote host. Connection to 192.168.5.81 closed. ppo at admin:/tmp$ ssh root at 192.168.5.81 root at 192.168.5.81's password: Last login: Tue Jul 30 14:10:49 2013 from pc-ppo.kh.ektos OpenBSD 5.3 (GENERIC.MP) #58: Tue Mar 12 18:43:53 MDT 2013 # ps -aux | grep ups root 2254 0.0 0.0 324 700 p0 S+ 5:29PM 0:00.00 grep ups # ps -aux

Hi Arjen, in server/upsd.c r731, you moved the call conf_load() from after check_perms() (~ l.1020) to before setupsignals() (~ l.989). The problem is that conf_load() needs to open the ups driver socket, and it assumes that STATEPATH is the current working directory. The directory is only set in l.1016. Therefore, the first attempt to open a socket will always fail. From the user's point of view: Can't connect to UPS [mge] (mge): No such file or directory The socket is later opened on the second attempt, but only afte...

Model: Tripp-lite OMNIVS1500 Error: Network UPS Tools - UPS driver controller 2.2.1- Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.11 (2.2.1-) Warning: This is an experimental driver. Some features may not function correctly. Detected a UPS: unknown/unknown libusb_set_report() returned -1 instead of 8 Could not reset watchdog. Please send model information to nut-upsdev mailing

...om sunfreeware libiconv-1.14-sol10-sparc-local gcc-3.4.6-sol10-sparc-local make-3.82-sol10-sparc-local libintl-3.4.0-sol10-sparc-local Working from Mike Nowak's notes at: https://blogs.oracle.com/mikey/entry/network_ups_tools_on_solaris > ./configure --prefix=/opt/nut --with-statepath=/var/ups --with-user=ups --with-group=ups returns alright, but the subsequent "make" fails with: > make[1]: Entering directory `/opt/downloads/nut-2.6.5/common' > /bin/bash ../libtool --tag=CC --mode=link gcc -I../include -g -O2 -Wall -Wsign-compare -o libparseconf.la pars...

Anybody knows what configure command settings FreeNAS use to compile NUT? More info on my journey: http://forums.freenas.org/index.php?threads/nobreak-bz1200-br-back-ups-rs-1200va-600w-bivolt-115-nt.20247/ Thanks Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: