similar to: kernel update to 3.12.5-1, now: upsd[617]: getaddrinfo: Servname not supported for ai_socktype

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

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

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 updated as well? I am

On 12/16/2013 09:23 PM, Charles Lepple wrote: > Not sure - I didn't write the getaddrinfo() code in upsd, but it seemed to > follow all of the recommendations on how to use that function. So if there is > a way to fix it in the NUT code, I am not aware of it (and would appreciate > any updates if that turns out to be the case). > > The odd part is that it looks like you went

On 12/17/2013 10:43 AM, David C. Rankin wrote: > Huh? 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

On Dec 17, 2013, at 1:08 PM, David C. Rankin wrote: > On 12/17/2013 10:43 AM, David C. Rankin wrote: >> Huh? 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

Now hold on there... you said the problem started when you updated kernels - not when you changed the config file - did you change the config file or was it wrong before and the old kernel accepted it anyway? ted On 12/17/2013 10:08 AM, David C. Rankin wrote: > On 12/17/2013 10:43 AM, David C. Rankin wrote: >> Huh? Why the : in Servname? So I just hardwired it passing the port

All, I have built and installed nut from git on Archlinux. It uses the usbhid 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]:

On 12/14/2013 09:04 PM, Charles Lepple wrote: >> Is there someway nut can be modified to probe the 0664 permission usb >> devices >>> and then connect as root before dropping permissions back to the "nut" >>> gid? > Given that the udev method should still work (and seems to, for handcrafted > udev rules files), I would like to run that to ground first.

On 12/16/2013 09:06 AM, Charles Lepple wrote: > If you want, we can take a look at the output of the aforementioned udevd > command from your system. Please compress the output, and if the list bounces > it, I'll extract the relevant portion from the bounce message. > > I have a funny feeling we might either have a Debian-specific dependency on > 91-permissions.rules, or

Hello openssh developers, I had built openssh-4.7p1 on arm-apple-darwin9 platform, but I get this error when I load sshd using launchd: root# launchctl load /Library/LaunchDaemons/com.openssh.sshd.plist errors on getaddrinfo(): nodename nor servname provided, or not known When I execute sshd directly, I don't get any warnings or error messages, but the sshd is not listening on the intended

Hi there, If I want to create email within my application (in production), how is this best achieved?? Following the railsspace tutorial, it only really suggests to use :smtp. I''d read on another site that to generate emails locally, i need to use :sendmail instead... However - I havent seen any decent examples of how to get this configured to be able to send emails within my local

On Dec 15, 2013, at 2:03 PM, David C. Rankin wrote: > On 12/14/2013 09:04 PM, Charles Lepple wrote: >>> Is there someway nut can be modified to probe the 0664 permission usb >>> devices >>>> and then connect as root before dropping permissions back to the "nut" >>>> gid? >> Given that the udev method should still work (and seems to, for

All, If the post "Samba 3.6 -> 4.1 change that prevent sharing / - mount error(13)" makes it to the list, I apologize, but it has been over a day 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:

I've just compiled 2.5.6 release on Tru64 V5.0A (configure detects alphaev67-dec-osf5.0, gcc release is a 3.1.1). rsync fails using rsync://<hostname>/ syntax. > lct@goliath(32) [rsync-2.5.6]$ ./rsync rsync://stitch/ > rsync: getaddrinfo: stitch 873: servname not supported for ai_socktype > rsync error: error in socket IO (code 10) at clientserver.c(83) Is there anyone else

http://bugzilla.mindrot.org/show_bug.cgi?id=310 Summary: sshd reporting ai_socktype errors when using ssh -X to server Product: Portable OpenSSH Version: -current Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: major Priority: P3 Component: sshd AssignedTo:

Anyone from the Tru64 camp have any comments? Ken, can you log this into http://bugzilla.mindrot.org/ to ensure we don't lose the bug report? Thanks. - Ben ---------- Forwarded message ---------- Date: Thu, 27 Jun 2002 11:25:02 -0400 (EDT) From: Ken Kleiner <ken at cs.uml.edu> To: secureshell at securityfocus.com Cc: Ken Kleiner <ken at saturn.cs.uml.edu> Subject: sshd and

hi, virt guys, This is Hongqing from Fedroa QA team. I try to forward the guest installation logs to host with virtio. I have used virsh edit <guestName> to add a channel, it works fine. I think it would be better if I can initialize it when I create the guest using virt-install, and virt-install also offers the option, I have tried below, but it does not work. virt-install

Accepting only Unix sockets can be a bit limiting; let's be more flexible. Eric Blake (2): nbd: Refactor Unix socket connection nbd: Support TCP socket plugins/nbd/nbdkit-nbd-plugin.pod | 36 ++++-- plugins/nbd/nbd.c | 175 ++++++++++++++++++++++-------- TODO | 3 - 3 files changed, 161 insertions(+), 53 deletions(-) -- 2.20.1

I had to apply the following patch to the clientname.c check_name() function before I could successfully use "hosts allow" in rsyncd.conf. Without the patch I kept getting "rsync: forward name lookup for ... failed: Host not found" errors. These errors were produced by the rsync daemon, and putting in a debugging statement revealed that the port_buf being used had a large