headers
Maxim Timofeyev | 2 Dec 2005 16:13
Picon

openntpd: dispatch_imsg in main: pipe closed

Hello!

# rpm -q openntpd
openntpd-3.7p1-owl2

# grep ntpd /var/log/messages | tail
Dec  2 17:45:12 tma ntpd[30527]: dispatch_imsg in main: pipe closed
Dec  2 17:45:12 tma ntpd[30527]: Terminating

# ps ax | grep ntpd | grep -v grep
19584 pts/3    S      0:00 /usr/sbin/ntpd -s
19591 ?        Ss     0:00 /usr/sbin/ntpd -s

--

-- 
Timofeyev Maxim
JabberID: tma <at> tma.spb.ru
E-Mail: tma <at> tma.spb.ru
WWW: http://tma.spb.ru
Permalink | Reply | 5 comments |
headers
Solar Designer | 3 Dec 2005 06:54
Favicon

Re: openntpd: dispatch_imsg in main: pipe closed

Maxim,

On Fri, Dec 02, 2005 at 06:13:12PM +0300, Maxim Timofeyev wrote:
> # rpm -q openntpd
> openntpd-3.7p1-owl2
> 
> # grep ntpd /var/log/messages | tail
> Dec  2 17:45:12 tma ntpd[30527]: dispatch_imsg in main: pipe closed
> Dec  2 17:45:12 tma ntpd[30527]: Terminating
> 
> # ps ax | grep ntpd | grep -v grep
> 19584 pts/3    S      0:00 /usr/sbin/ntpd -s
> 19591 ?        Ss     0:00 /usr/sbin/ntpd -s

It is not clear what you mean by this.  Is this a bug report?  If so,
what's the bug?  From the log file entries, it is seen that you had
terminated ntpd (one of its processes complained about the other's
death, but that's fine).  From the process list, it is seen that you
have ntpd running again.

Actually, I think there are a couple of things we could improve.  We
could make the log file messages less confusing.  We could also have
_both_ ntpd processes detach from the tty.  None of this is specific to
Owl (those are properties of OpenNTPD), but, yes, we could patch this.

--

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
(Continue reading)

Permalink | Reply | 4 comments |
headers
Maxim Timofeyev | 5 Dec 2005 13:46
Picon

Re: openntpd: dispatch_imsg in main: pipe closed

Hi!

It is a bug report.
ntpd started and terminating.

Solar Designer пишет:
> Maxim,
> 
> On Fri, Dec 02, 2005 at 06:13:12PM +0300, Maxim Timofeyev wrote:
>> # rpm -q openntpd
>> openntpd-3.7p1-owl2
>>
>> # grep ntpd /var/log/messages | tail
>> Dec  2 17:45:12 tma ntpd[30527]: dispatch_imsg in main: pipe closed
>> Dec  2 17:45:12 tma ntpd[30527]: Terminating
>>
>> # ps ax | grep ntpd | grep -v grep
>> 19584 pts/3    S      0:00 /usr/sbin/ntpd -s
>> 19591 ?        Ss     0:00 /usr/sbin/ntpd -s
> 
> It is not clear what you mean by this.  Is this a bug report?  If so,
> what's the bug?  From the log file entries, it is seen that you had
> terminated ntpd (one of its processes complained about the other's
> death, but that's fine).  From the process list, it is seen that you
> have ntpd running again.
> 
> Actually, I think there are a couple of things we could improve.  We
> could make the log file messages less confusing.  We could also have
> _both_ ntpd processes detach from the tty.  None of this is specific to
> Owl (those are properties of OpenNTPD), but, yes, we could patch this.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Solar Designer | 5 Dec 2005 17:43
Favicon

Re: openntpd: dispatch_imsg in main: pipe closed

On Mon, Dec 05, 2005 at 03:46:49PM +0300, Maxim Timofeyev wrote:
> It is a bug report.
> ntpd started and terminating.

This is still not clear enough.  Did it terminate immediately after
being started?  If not, then when did it terminate?  Are you sure this
was not intentional (not an action of a script, etc)?  Why did you
demonstrate that you have two other ntpd processes running, what was
this meant to say?  Please don't be so cryptic.

Obviously, we can't reproduce the problem from your report.  We didn't
even know what the problem you were trying to report is, and we have
the Owl-current package of OpenNTPD in use on many systems with no
problems.

> > On Fri, Dec 02, 2005 at 06:13:12PM +0300, Maxim Timofeyev wrote:
> >> # rpm -q openntpd
> >> openntpd-3.7p1-owl2
> >>
> >> # grep ntpd /var/log/messages | tail
> >> Dec  2 17:45:12 tma ntpd[30527]: dispatch_imsg in main: pipe closed
> >> Dec  2 17:45:12 tma ntpd[30527]: Terminating
> >>
> >> # ps ax | grep ntpd | grep -v grep
> >> 19584 pts/3    S      0:00 /usr/sbin/ntpd -s
> >> 19591 ?        Ss     0:00 /usr/sbin/ntpd -s

--

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
(Continue reading)

Permalink | Reply | 2 comments |
headers
Maxim Timofeyev | 6 Dec 2005 09:15
Picon

Re: openntpd: dispatch_imsg in main: pipe closed

Hmm. I got a bit confused with its behavior. I've been using OpenNTPD
for quite a while, but I would never encounter such behaviour.
First, it used to log it's time sync actions:

Nov 24 14:35:42 www ntpd[419]: adjusting local clock by -192.952421s
Nov 24 14:40:03 www ntpd[419]: adjusting local clock by -192.819198s
It doesn't any more now.

It would also never write such messages:
Dec  6 10:25:22 www ntpd[5506]: dispatch_imsg in main: pipe closed
Dec  6 10:25:22 www ntpd[5506]: Terminating

Moreover,
it launches and works ok, but the following log string is confusing:
Dec  6 10:25:22 www ntpd[5506]: dispatch_imsg in main: pipe closed
I believe that the termination notification string would be enough.

Solar Designer пишет:
> On Mon, Dec 05, 2005 at 03:46:49PM +0300, Maxim Timofeyev wrote:
>> It is a bug report.
>> ntpd started and terminating.
> 
> This is still not clear enough.  Did it terminate immediately after
> being started?  If not, then when did it terminate?  Are you sure this
> was not intentional (not an action of a script, etc)?  Why did you
> demonstrate that you have two other ntpd processes running, what was
> this meant to say?  Please don't be so cryptic.
> 
> Obviously, we can't reproduce the problem from your report.  We didn't
> even know what the problem you were trying to report is, and we have
(Continue reading)

Permalink | Reply | 1 comment |
headers
Solar Designer | 6 Dec 2005 16:09
Favicon

Re: openntpd: dispatch_imsg in main: pipe closed

On Tue, Dec 06, 2005 at 11:15:04AM +0300, Maxim Timofeyev wrote:
> Hmm. I got a bit confused with its behavior. I've been using OpenNTPD
> for quite a while, but I would never encounter such behaviour.
> First, it used to log it's time sync actions:
> 
> Nov 24 14:35:42 www ntpd[419]: adjusting local clock by -192.952421s
> Nov 24 14:40:03 www ntpd[419]: adjusting local clock by -192.819198s
> It doesn't any more now.

This is the documented behavior.  It would only log time adjustments
larger than 128ms.

> It would also never write such messages:
> Dec  6 10:25:22 www ntpd[5506]: dispatch_imsg in main: pipe closed
> Dec  6 10:25:22 www ntpd[5506]: Terminating

Well, I don't know why not.  Maybe you were using an older version.

> Moreover,
> it launches and works ok, but the following log string is confusing:
> Dec  6 10:25:22 www ntpd[5506]: dispatch_imsg in main: pipe closed
> I believe that the termination notification string would be enough.

Yes, I agree that this is confusing.  It's a side effect of privsep.

--

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
(Continue reading)

Permalink | Reply | 0 comments |
headers
Solar Designer | 9 Dec 2005 16:26
Favicon

Owl-current 2005/12/08 ISO; JtR Post.Office MD5 and Lotus Domino salted hashes support

Hi,

There's a new Owl-current ISO-9660 image (dated 2005/12/08) available
for download under /pub/Owl/current/iso on the FTP mirrors:

	http://www.openwall.com/Owl/DOWNLOAD.shtml

The new installer now implements an ncurses/CDK-based user interface,
although this new UI is not enabled by default yet.  To enable it,
please invoke the "settle" and "setup" programs with the new "-m"
option, -- and please provide your feedback (report any bugs and
anything that is confusing, provide any suggestions for improvement,
etc.)

Besides the installer, the following other components have been
significantly updated since the last ISO snapshot (September 13, 2005):
util-linux, findutils, CVS, tcsh, OpenSSL, RPM, elfutils-libelf, SILO,
setarch (replaces sparc32), kbd, LILO, m4, net-tools, coreutils, zlib,
strace, file, SysVinit, modutils, Linux-PAM, procmail, Postfix, Nmap,
glibc, sed, patch, quota, tar, traceroute, grep, cpio, libpcap, GnuPG,
vsftpd, Perl, and the Linux kernel.  The following new packages have
been added: CDK, BIND, OpenNTPD, tinycdb, PCRE, indent.

Please refer to the change log for descriptions of these changes:

	http://www.openwall.com/Owl/CHANGES-current.shtml

In order to not "spam" the announcement list with multiple messages, I'd
like to also use this opportunity to mention that two new contributed
patches are now available off John the Ripper homepage at:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard Fischer | 12 Dec 2005 11:06

groff and fake-libs

The current groff package still requires libstdc++-libc6.1-2.so.3. So
'NEED_FAKE' should be set to 'yes' in installworld.sh, to get an
error-free installation. Or you have to install libstdc++-v3-compat,
groff and man by hand after an 'make installworld'.

BTW: the new package 'elftoaout' is missing, but listed in
installorder.conf

Greetings
Bernhard
Permalink | Reply | 2 comments |
headers
Solar Designer | 12 Dec 2005 11:18
Favicon

Re: groff and fake-libs

On Mon, Dec 12, 2005 at 11:06:08AM +0100, Bernhard Fischer wrote:
> The current groff package still requires libstdc++-libc6.1-2.so.3.

No, it does not.

Maybe you were updating a system where the installed groff required that
library?  If so, NEED_FAKE=yes should have been set by installworld.sh
(it's set on all updates of existing systems).  I have no idea how you
managed to run into a problem with that.

I'd appreciate more detail on what you were doing (new install vs.
update, which version of Owl you were updating, whether or not you had
third-party packages installed on top of that).

> BTW: the new package 'elftoaout' is missing, but listed in
> installorder.conf

elftoaout is not new, it existed in Owl 1.0 and it's still around, but
it is specific to the SPARC architecture.  It should be missing on x86.

Yes, we might need to enhance installworld to recognize packages which
are not supposed to exist for the target architecture such that
confusing "Missing ..." messages would not be produced for those.

Thanks,

--

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernhard Fischer | 12 Dec 2005 16:50
Picon
Favicon

Re: groff and fake-libs

Am Mo 12.12.2005 11:18 schrieb Solar Designer <solar <at> openwall.com>:

> On Mon, Dec 12, 2005 at 11:06:08AM +0100, Bernhard Fischer wrote:
> > The current groff package still requires libstdc++-libc6.1-2.so.3.
> 
> No, it does not.
> 
> Maybe you were updating a system where the installed groff required
> that
> library?  If so, NEED_FAKE=yes should have been set by installworld.sh
> (it's set on all updates of existing systems).  I have no idea how you
> managed to run into a problem with that.
> 

I'm using the current iso-image as my base system, but i exchanged all
RPMS whith those from the mirror. It turned out that my groff package
(groff-1.17.2-owl2.i386.rpm) from my package-pool was an older one (same
version but from Dec. 14. 2003). Version and release nerver changed
since this date. Because of that, my package-pool got invalid.

Sorry for making a lot of fuss ... but now my own mirror is uptodate ;)

Thanks
Bernhard
Permalink | Reply | 0 comments |

Gmane