search for: phoinix

...les, All, I just updated the kernel on my Arch box (the one we have been working on nut with on this list). Now upsd fails to start. (upsdrvctl is fine). I've posted working then -- Reboot -- the failing log information below. The 'Reboot' was for the kernel upgrade: Dec 14 14:02:00 phoinix systemd[1]: Starting Network UPS Tools - power devices information server... Dec 14 14:02:00 phoinix upsd[32616]: fopen /var/state/ups/upsd.pid: No such file or directory Dec 14 14:02:00 phoinix upsd[32616]: listening on 192.168.7.16 port 3493 Dec 14 14:02:00 phoinix upsd[32616]: listening on ::1 p...

All, Looking at logs for 4.1.3 on my standalone server (Archlinux w/systemd), I get an error launching samba with 'systemctl start samba.service' telling me I should start all individual daemons instead (nmbd/smbd/winbindd) of using samba.service: Jan 07 22:25:07 phoinix systemd[1]: Starting Samba AD Daemon... Jan 07 22:25:07 phoinix samba[29948]: [2014/01/07 22:25:07.734014, 0] ../source4/smbd/server.c:370(binary_smbd_main) Jan 07 22:25:07 phoinix samba[29948]: samba version 4.1.3 started. Jan 07 22:25:07 phoinix samba[29948]: Copyright Andrew Tridgell and the Sa...

...if (v == EAI_SYSTEM) { fatal_with_errno(EXIT_FAILURE, "getaddrinfo"); } fatalx(EXIT_FAILURE, "getaddrinfo: %s", gai_strerror(v)); } I rebuilt nut and ran it, the error log contained: Dec 17 10:21:01 phoinix upsd[27151]: =========== Error Block Hit ============ Dec 17 10:21:01 phoinix upsd[27151]: getaddrinfo : Servname not supported for ai_socktype Dec 17 10:21:01 phoinix upsd[27151]: Server addr (Nodename) : 192.168.7.16 Dec 17 10:21:01 phoinix upsd[27151]: Server port (Servname)...

On 12/16/2013 08:01 PM, Charles Lepple wrote: > On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: > >> > Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for >> > ai_socktype > [...] >> > The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't see what >> > could have changed. How do I attempt to further debug/fix this? > getaddrinfo(3) is a libc function...

On Dec 16, 2013, at 10:11 PM, David C. Rankin wrote: > On 12/16/2013 08:01 PM, Charles Lepple wrote: >> On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: >> >>>> Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for >>>> ai_socktype >> [...] >>>> The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't see what >>>> could have changed. How do I attempt to further debug/fix this? >> getaddrinfo(3) i...

...bhid driver. Beginning a couple of years ago, nut begin failing to run on Archlinux without 'tweaking' or 'fudging' the install. There are two primary problems: (1) upsdrvctl cannot be launched normally i.e. (/usr/sbin/upsdrvctl start) without failing to connect: Dec 14 02:24:39 phoinix systemd[1]: Starting Network UPS Tools - power device driver controller... Dec 14 02:24:39 phoinix systemd[1]: nut-driver.service: control process exited, code=exited status=1 Dec 14 02:24:39 phoinix systemd[1]: Failed to start Network UPS Tools - power device driver controller. Dec 14 02:24:39 pho...

...exit-code) since Wed 2018-11-21 17:59:29 CST; 3s ago Docs: man:smbd(8) man:samba(7) man:smb.conf(5) Process: 10684 ExecStart=/usr/bin/smbd --foreground --no-process-group $SMBDOPTIONS (code=exited, status=255) Main PID: 10684 (code=exited, status=255) Nov 21 17:59:29 phoinix systemd[1]: Starting Samba SMB Daemon... Nov 21 17:59:29 phoinix smbd[10684]: [2018/11/21 17:59:29.478644, 0] ../source3/auth/auth_util.c:1382(make_new_session_info_guest) Nov 21 17:59:29 phoinix smbd[10684]: create_local_token failed: NT_STATUS_ACCESS_DENIED Nov 21 17:59:29 phoinix smbd[10684]:...

...and I have no indication that the post ever made it to the list. The issue is that in versions prior to 4.x, I was able to create a root share in samba, but now, something prevents it from being mounted. The relevant smb.conf is: security = user admin users = david [config] comment = Phoinix Config (Archlinux) path = / valid users = david force user = root force group = root browseable = no writeable = Yes With 3.6.6-1 all works as expected. However in 4.1.2-1 a mount error(13) is received when attempting to mount the share on a remote linux host: 16:07 alchemy:~&...

...Why the : in Servname? So I just hardwired it passing the port "Servname" > as "3493" (could have just used "nut" from /etc/services): Sheepishly looking for a place to hide.... Yes there was a ':' there all right. Seems I was hit by a vi error: [12:04 phoinix:/etc/ups] # grep 3493 *.conf upsd.conf:LISTEN 127.0.0.1 3493 upsd.conf:LISTEN ::1 3493 upsd.conf:LISTEN 192.168.7.16 :3493 GRRR! I hate it when that happens. Sorry for the noise... -- David C. Rankin, J.D.,P.E.

On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote: > Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not supported for > ai_socktype [...] > The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I don't see what > could have changed. How do I attempt to further debug/fix this? getaddrinfo(3) is a libc function - is it possible that libc was upda...

...ys and have been though a few breakages due to version updates along the way. It seems we have hit one again in the 4.4 to 4.5 update. Specifically, the update was samba-4.4.5 => samba-4.5.0 There were no changes made to smb.conf, but the following attempted mount failed using: mount.cifs //phoinix/samba /mnt/phx -o username=david,uid=1000,credentials=/home/adm/mountcfile,noperm There are no entries in the logs telling me why the mount fails, it just fails. Were there new share connection requirements put in place in 4.5? -- David C. Rankin, J.D.,P.E.

...t hardwired it passing the port "Servname" >> as "3493" (could have just used "nut" from /etc/services): > > Sheepishly looking for a place to hide.... > > Yes there was a ':' there all right. Seems I was hit by a vi error: > > [12:04 phoinix:/etc/ups] # grep 3493 *.conf > upsd.conf:LISTEN 127.0.0.1 3493 > upsd.conf:LISTEN ::1 3493 > upsd.conf:LISTEN 192.168.7.16 :3493 > > GRRR! I hate it when that happens. > > Sorry for the noise... > >

...hardwired it passing the port "Servname" >> as "3493" (could have just used "nut" from /etc/services): > > Sheepishly looking for a place to hide.... > > Yes there was a ':' there all right. Seems I was hit by a vi error: > > [12:04 phoinix:/etc/ups] # grep 3493 *.conf > upsd.conf:LISTEN 127.0.0.1 3493 > upsd.conf:LISTEN ::1 3493 > upsd.conf:LISTEN 192.168.7.16 :3493 > > GRRR! I hate it when that happens. Thanks for taking the time to track this down. It's another thing we need to add to the list of areas that ne...

On Dec 14, 2013, at 4:23 PM, David C. Rankin wrote: > Do you know if the problem with upsdrvctl being able to probe/connect to the > usb devices is the result of some default permission change in Linux in general. > It seems to me that since nut used to work right out-of-the-box, then all/most > distros must have had the default permissions on usb nodes set to 0666, where >

On 12/14/2013 02:06 PM, David C. Rankin wrote: > Charles, > > Setting uid:gid to root:nut on /dev/bus/usb/004/002 seemed to be the issue. > The question now become how to automate this process so that the user isn't > required to manually hunt down the usb dev and change gid to the nut gid? So > far, either manually setting the gid or hand-rolling the udev files to do the

...vices have that information as well. I know there are differences. My ups does not report an ATTRS{serial} on the device itself when udevadmin is called. It does on the parent device, but only the generic ATTRS{serial}=="0000:00:04.0" for bus 4. There is useful information though: [14:37 phoinix:/srv/http/htdocs/nut] # udevadm info --attribute-walk --name /dev/bus/usb/004/002 Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can...