ELOG Forum

Demo Discussion

Forum Config Examples Contributions Vulnerabilities

Discussion forum about ELOG, Page 428 of 808

Not logged in

Find | Login | Help

Full | Summary | Threaded | Hide attachments

6457 Entries

Goto page Previous 1, 2, 3 ... 427, 428, 429 ... 806, 807, 808 Next

Sun Jun 7 06:29:55 2009

Gerardo Pruneda

gerardopruneda@yahoo.com

Question

Windows

2.7.6

I can not access the Logbook from another machine

I need some guidedance on how to access the logbook from another computer. I installed the logbook on a Windows server machine and started the logbook using port 81.

I can connect to the logbook on the same machine, but I can not access it from another machine on the same network.

I already confirm that the windows firewall is not enable.

66383

Fri Jun 5 14:13:52 2009

Re: Embedded images break when moving from one book to another.

Stefan Ritt wrote:

Mike wrote:

This is a major improvement. The only issue now is when we embed an image in the body of the message elog makes a nice thumbnail. When you move the message to another logbook the thumbnail doesn't work and instead it shows the MASSIVE full size version of the picture instead. Is that possible to fix?

Thanks Stefan!

Mike

Can you try revision #2206?

Stefan,

Works perfectly, thanks for the fix you rock!

Mike

66382

Fri Jun 5 13:18:00 2009

Re: elogd dies after receiving second SIGHUP

> Here is the patch.  It works under both Solaris and Linux.

Thanks! I put that into revision #2207.

66381

Fri Jun 5 12:42:55 2009

Re: Embedded images break when moving from one book to another.

Mike wrote:

Thanks Stefan!

Mike

Can you try revision #2206?

66380

Fri Jun 5 12:02:45 2009

David Pilgram

David.Pilgram@epost.org.uk

Question

Linux

2.7.6-2191

Re: Moving entry (and replies) from one log book to another

Thanks Stefan,  Downloading shortly and I'll let you know ;-)
> > Hi Stefan,
> > 
> > When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
> > the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
> > cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
> > your FAQ about marking of whole threads).
> > 
> > In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
> > ID number.
> > 
> > Thanks,
> > 
> > David Pilgram.
> 
> I have implemented this feature in revision 2205. You need to set the new flag "Preserve IDs = 1" in the 
> configuration. I have not tested this extensively, but I'm sure you will do it ;-)

66379

Fri Jun 5 11:29:43 2009

Re: Moving entry (and replies) from one log book to another

> Hi Stefan,
> 
> When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
> the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
> cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
> your FAQ about marking of whole threads).
> 
> In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
> ID number.
> 
> Thanks,
> 
> David Pilgram.

I have implemented this feature in revision 2205. You need to set the new flag "Preserve IDs = 1" in the 
configuration. I have not tested this extensively, but I'm sure you will do it ;-)

66378

Fri Jun 5 10:51:17 2009

Re: Memory leak in 2.76 elogd.exe

jon huang wrote:

Hi,

There's seems to be a memory leak with elogd.exe running windows. I had this problem with older version of elogd.exe, i've just upgrade to the latest and the problems still exist. I've had this issue with earlier versions. I've just upgrade elog to the latest 2.76 version. The memory leak still persist. I really appreciate if you or anyone here can help me resolve this issue.

ELOG has been carefully designed not to contain memory leaks. The server for this forum for example runs for months without problem:

[ritt@midas ~]$ ps aux | grep elogd

elog 1958 0.4 3.1 39412 32940 ? Ss May09 178:16 /usr/local/sbin/elogd -D -c /usr/local/elog/elogd.cfg

So if you have a problem, it must be specific to your installation. You should note that if you up- or download big attachents, memory gets allocated for some network buffers to contain these attachments. The buffer is kept to contain the largest attachment, it will never shrink. But once established, it will also not grow. If you see however a constant increase in memory consumption, I would appreciate if you tell me how you do this. Like which configuration you use, if you just read entries or also upload them, etc. etc. Once I can reproduce exactly your problem, I can try to fix it.

66377

Thu Jun 4 18:49:29 2009

Re: elogd dies after receiving second SIGHUP

> > > > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > > > This was observed on Solaris 10 (SPARC).
> > > > The documentation states that elogd should re-read configuration after receiving SIGHUP.
> > > 
> > > I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe 
> > > you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to 
> > > start the daemon interactively and see what exactly happens if you send several SIGHUPs.
> > 
> > The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
> > is called.  Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.
> > 
> > The solution is to use the POSIX sigaction() call instead of signal(). 
> 
> Can you try to modify the signal() calls into sigaction(). If this really works under Solaris, I will incorporate this 
> then into the distribution.

Here is the patch.  It works under both Solaris and Linux.

Attachment 1: elogd-signal.patch

*** src/elogd.c-orig	2009-04-14 04:16:02.000000000 -0400
--- src/elogd.c	2009-06-04 11:33:31.337804000 -0400
***************
*** 27553,27558 ****
--- 27553,27565 ----
     SSL_CTX *ssl_ctx;
  #endif
  
+    /*
+     * sigaction structs
+     */
+    struct sigaction ctrlc_handle;
+    struct sigaction ignore_handle;
+    struct sigaction hup_handle;
+ 
     i_conn = content_length = 0;
     net_buffer_size = 100000;
     net_buffer = xmalloc(net_buffer_size);
***************
*** 27708,27718 ****
        close(fd);
     }
  
!    /* install signal handler */
!    signal(SIGTERM, ctrlc_handler);
!    signal(SIGINT, ctrlc_handler);
!    signal(SIGPIPE, SIG_IGN);
!    signal(SIGHUP, hup_handler);
     /* give up root privilege */
     if (geteuid() == 0) {
        if (!getcfg("global", "Grp", str, sizeof(str)) || setegroup(str) < 0) {
--- 27715,27739 ----
        close(fd);
     }
  
!    /*
!     * install signal handlers 
!     */
!    ctrlc_handle.sa_handler = ctrlc_handler;
!    sigemptyset( &ctrlc_handle.sa_mask );
!    ctrlc_handle.sa_flags = 0;
! 
!    sigaction(SIGTERM, &ctrlc_handle, NULL);
!    sigaction(SIGINT, &ctrlc_handle, NULL);
! 
!    ignore_handle.sa_handler = SIG_IGN;
!    sigaction(SIGPIPE, &ignore_handle, NULL);
! 
!    hup_handle.sa_handler = hup_handler;
!    sigemptyset( &hup_handle.sa_mask );
!    hup_handle.sa_flags = 0;
!    sigaction(SIGHUP, &hup_handle, NULL);
! 
! 
     /* give up root privilege */
     if (geteuid() == 0) {
        if (!getcfg("global", "Grp", str, sizeof(str)) || setegroup(str) < 0) {

Goto page Previous 1, 2, 3 ... 427, 428, 429 ... 806, 807, 808 Next

ELOG V3.1.5-3fb85fa6