syslogd failing to start (Full Version)

All Forums >> [SFU / Interix / SUA Technology] >> Tools Discussion Forum



Message

ajhalls -> syslogd failing to start (Dec. 22, '04, 10:07:10 AM)

Hi gang
I am having problems getting syslogd to start. No error messages or logging when started either by the init strips or manually by /usr/sbin/syslogd.

Get the following output when starting with debug option
/usr/sbin/syslogd -d
setsockopt(SO_EXCLUSIVEADDRUSE): success
syslogd: syslog/udp: unknown service
logmsg: pri 53, flags 4, from ra, msg syslogd: syslog/udp: unknown service

From trolling the net it appears that the message is related to not being able to get the udp socket and the usual fixes in syslog.conf do not relate as there is no entries there to do with remote logging.

I am running WinXP SP2 with the firewall turned off, (I also have placed an exception for udp port 154 in the exceptions list anyway)

Any suggestions ?



Rodney -> RE: syslogd failing to start (Dec. 22, '04, 10:59:56 AM)

Look in the file /etc/services (it's a symbolic link to the Win32 file)
for a line starting with "syslog" it should say:
 
syslog            514/udp

The error message you are getting indicates that this line is missing.
Add it back into the file and things should then work.



ajhalls -> RE: syslogd failing to start (Dec. 22, '04, 11:20:45 AM)

Hi Rodney
That is not the problem, that was the first thing I checked & rechecked
entry is there and the file is owned by Administrator and is group & world readable.

I have used Sysinternals TcpView to check if any other thing is bound to that port. Nothing is showing.
Andy H



Rodney -> RE: syslogd failing to start (Dec. 22, '04, 12:32:07 PM)

The error message comes from the error message specifically from syslogd
when the getservbyname() API call fails. This usually indicates that the
entry/line is missing in the /etc/services file, or, more correctly, from the
file that /etc/services symlinks to because WinSock is returning the information.
The getservbyname() call goes through the WinSock driver. So if the file is okay
then it must be something that is changing/setting/instructing WinSock to not
give this information. But what if no firewall interference?

I assume you've given ye olde Windows try of a reboot.



ajhalls -> RE: syslogd failing to start (Dec. 22, '04, 3:02:48 PM)

The windows reboot was number 2 on the list of things done after check the services file.
From the time stamps on the error logs I did not reenable syslogd after I re-installed SFU a while back (early September), they all have a date of Nov 8 2003, which I think is MS's creation date for the SFU 3.5 installation package.

I will re-enable the firewall and check with and with-out the exception added.
Andy H

OK Have re-enabled the firewall, and rebooted. No change to report. I will leave the firewall enabled for the time being.

Andy H



Rodney -> RE: syslogd failing to start (Dec. 22, '04, 5:00:37 PM)

Here's something for you to try. It's not the final product that I'd release.
But this is a port of syslogd that uses BIND9 instead of WinSock for
a number of service calls. It's not in a package so you'll need to drop it
into your /usr/sbin and check the file mode. Keep a copy of the original.
 
    ftp://ftp.interopsystems.com/pub/syslogd



ajhalls -> RE: syslogd failing to start (Dec. 23, '04, 5:33:07 AM)

Hi Rodney
No luck with new version of syslogd same error as before.
syslogd: syslog/udp: unknown service
logmsg: pri 53, flags 4, from ra, msg syslogd: syslog/udp: unknown service
Logging to CONSOLE /dev/null

The following are details of the version of winsock that are installed on this system.
File c:\windows\system32\winsock.dll
Size 2.80 KB (2,864 bytes)
Version 3.10

File c:\windows\system32\wsock32.dll
Size 22.00 KB (22,528 bytes)
Version 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)

Andy H



Rodney -> RE: syslogd failing to start (Dec. 23, '04, 10:24:57 AM)

> No luck with new version of syslogd same error as before.

Okay.
At least now we have a syslogd that the I can modify to see if more
info can be gleened out. I'll double check about the getservbyname()
as using the BIND9 version. Then I'll get back to you (here).



Rodney -> RE: syslogd failing to start (Dec. 23, '04, 11:51:29 AM)

I see that my version isn't liking the Win32 line endings in /etc/services.
Try using flip -u /etc/services and then see if it'll restart okay.
I'll make adjustments for handling the Win32 file endings for a release.



Rodney -> RE: syslogd failing to start (Dec. 23, '04, 12:23:12 PM)

I've refreshed the syslogd sitting in ftp://interopsystems.com/pub
to handle text files that have Win32/DOS file endings. Actually it's
an update to BIND9. So I'll post a new version of that later today.

Anyway this version is 100% reading /etc/service directly.
The DOS line endings gave the can't find error earlier. This version
will handle it if you don't want to flip the file.



ajhalls -> RE: syslogd failing to start (Dec. 23, '04, 7:34:47 PM)

Hi Rodney
That did it your version of syslogd is up and running. I have not download the updated version as yet.
The following message was placed in /var/adm/log/messages:
Dec 24 10:55:2^@ ra syslogd: restart

Note the ^@ , less thinks that this is now a binary file , will download the update and retest.

Andy H


Test new version still have ^@ in syslogd startup and shutdown messages.

Big problem no syslog messages are being logged.
using logger as follows
logger -p daemon.info -t TEST "test ahalls 12876309"

should have had a message in both the daemon and message log files nothing is appearing.
Also as I am running syslogd with the debug switch no processing from the logger command is indicated.

Output from stdout of /usr/sbin/syslogd -d:
off & running....
init
cfline(*.err;kern.*;auth.notice;authpriv.none;mail.crit /dev/console)
syslogd: /dev/console: Device not configured
logmsg: pri 53, flags 4, from ra, msg syslogd: /dev/console: Device not configured
Logging to CONSOLE /dev/null
cfline(*.notice;*.info;authpriv,ftp.none;mail.crit /var/adm/log/messages)
cfline(mail.* /var/adm/log/mail)
cfline(ftp.* /var/adm/log/ftp)
cfline(daemon.* /var/adm/log/daemon)
cfline(authpriv.* /var/adm/log/secure)
8 3 2 3 5 3 3 3 3 3 X 3 3 3 3 3 3 3 3 3 3 3 3 3 X UNUSED:
6 6 2 6 6 6 6 6 6 6 X X 6 6 6 6 6 6 6 6 6 6 6 6 X FILE: /var/adm/log/messages
X X 8 X X X X X X X X X X X X X X X X X X X X X X FILE: /var/adm/log/mail
X X X X X X X X X X X 8 X X X X X X X X X X X X X FILE: /var/adm/log/ftp
X X X 8 X X X X X X X X X X X X X X X X X X X X X FILE: /var/adm/log/daemon
X X X X X X X X X X 8 X X X X X X X X X X X X X X FILE: /var/adm/log/secure
logmsg: pri 56, flags 4, from ra, msg syslogd: restart
Logging to FILE /var/adm/log/messages
syslogd: restarted
readfds = 0x8
readfds = 0x8
readfds = 0x8


Andy H



Rodney -> RE: syslogd failing to start (Dec. 23, '04, 8:02:23 PM)

Great.

> Note the ^@ , less thinks that this is now a binary file , will download the update and retest.

I'll look into that here.

I'm going to, for readers in general, go into a bit of Interix history as a preface
to another comment.
When syslog was ported for OpenNT (the orginal name of Interix) there were no AF_UNIX
sockets. So all of the syslog() et al API calls go through the AF_INET. The same exists
on the syslogd end. Syslogd only listens on AF_INET. For Firebrand (what
became 3.0) AF_UNIX sockets were added but only for SOCK_STREAM. The intent was that
SOCK_DGRAM would be added later. The code then (as Interix) shifted to Microsoft.
The state of AF_UNIX only doing SOCK_STREAM has continued to Interix 3.5. The same as well
for how the CD ships syslog() et al and syslogd. Now over AF_INET the syslog messages
are send via SOCK_DGRAM. For those of you wondering SOCK_DGRAM does udp transmission
but preserves order and size for a sent "chunk" of information. But like regular udp
the order of arrival isn't guaranteed and a fixed stream isn't needed. This helps keep
the syslogd code lightweight.

So with the new syslogd things are a little different because a portion of the
functionality is now done by BIND (instead of the subsystem calling WinSock). This
also opens the opportunity to use AF_UNIX. Microsoft ships Interix with syslogd
off to avoid a flooding DoS on the AF_INET connection (though if this is a problem
then I think you have much more serious network security problems). Alas, as mentioned
above, SOCK_DGRAM with AF_UNIX isn't there isn't available; only SOCK_STREAM. And turned
on AF_UNIX means syslog() et al (as shipped off the CD) know nothing about what's
happening. So I'm going to make a syslogd release that matches the old behavior.
Then I'm going to work a one that does AF_UNIX (in an unusual manner) with matching
syslog() et al changes. I'd love to just implement AF_UNIX/SOCK_DGRAM (the correct fix)
but that's not in possible :-(

If people want to provide feedback please do.



ajhalls -> RE: syslogd failing to start (Dec. 23, '04, 9:26:08 PM)

UPDATE
your new syslogd is logging ok, just changed from win32 BIND to Interix BIND and logging messages are being placed into the daemon log file.

It looks like the command line util logger may need a look at.

Any time you require a tester for this stuff as the saying goes "I'm free"

Andy H



Rodney -> RE: syslogd failing to start (Dec. 30, '04, 10:04:54 PM)

> It looks like the command line util logger may need a look at.

I don't know if there is a particular problem you're finding with logger.
But with the new syslogd using a local-only communications method it
makes sense to have a new logger which uses this method too. So I have
an updated logger (which also made for good testing).

In doing this it makes sense to update others utilities and daemons using
syslog. Then the new syslogd can run in "secure mode"; it can run
in "unsecure mode" for backward support. But best to move forward. It
would also make sense (well, at least I think so [:)]) that syslogd
and logger get released at the same time as some/most of these other
utilities/daemons.

The BIG QUESTION then, for all to contribute to:
What's your priority list for getting updated?

Don't be a lurker! Join as a member and respond today! [:)]



ajhalls -> RE: syslogd failing to start (Dec. 31, '04, 6:10:31 AM)

Hi Rodney
I did not expect to hear from you until after the new year!

Syslogd is not recieving anything from logger - I use logger to test syslog config changes and in scripts..


I would have said ssh as one of the first - however that package seams to be logging OK with the new daemon. The problem with the passwordless login for Administrator was what caused me to chase why syslogd was not working (see another thread for that pronblem).

Was it a code change or a link change you had to do for the new Syslogd ?

Andy H



Rodney -> RE: syslogd failing to start (Dec. 31, '04, 11:47:27 AM)

> Was it a code change or a link change you had to do for the new Syslogd ?

It's a bit of everything at this point.
I don't have the code that Microsoft is using. So it's a fresh port of syslogd.
The new links are against the new BIND library and my libport (which has portability
enhancement but is also slowly replacing libc). I think for what was happening with
your system the link to the new BIND was key. The port I dropped in /pub was wacked
to just do AF_INET/datagram (the standard) to match the "old" behavior of the syslogd
that ships on the CD.

I'm going to guess that for logger it's the same. A link against the new BIND is key.

But I redid the syslog() et al API's to use a FIFO for local syslog communication instead
of AF_INET/datagram. I would have used AF_UNIX/datagram if it were implemented. But with
AF_UNIX it's just stream right now. So FIFO's it is.

Logger links to this new syslog() API (it's part of libport now). The syslogd
I dropped in /pub doesn't know about the FIFO. I have both logger and syslogd
packaged up to go. Using the new packaged syslogd will mean using the "-u" option
to pick up syslog messages from non-updated utilities. So most people will need to run with
"-u" for a while.

Relinking openssh is easy enough.

I'll post up the syslogd and logger packages later today.



Rodney -> RE: syslogd failing to start (Dec. 31, '04, 2:00:06 PM)

The syslogd and logger packages are now posted.
Openssh is building now and then will need to be tested.



ajhalls -> RE: syslogd failing to start (Dec. 31, '04, 9:54:27 PM)

Both syslogd & logger installed and tested OK.

Change required for /etc/init.d/syslog script

SYSLOGD=/usr/sbin/syslogd
needs to be changed to
SYSLOGD="/usr/local/bin/syslogd -u"

Andy H



Rodney -> RE: syslogd failing to start (Jan. 1, '05, 3:21:36 AM)

The openssh package has now been updated too.



ajhalls -> RE: syslogd failing to start (Jan. 1, '05, 11:34:43 AM)

Hi Rodney
openssh-3.9.0.1.2 is a no goer, closes connection as soon as authentication and environment setup has occured.

See my message in "SFU/Interix - getting started"/"passwordless logon for Administrator using SSH failing " for more information.

Andy H



Page: [1] 2   next >   >>



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.047