Hi,

I really don't understand why elogd cannot run by root but it runs by a user.

I've put elog deamon in /etc/init.d. So it didn't bring up, but it runs if I run it by user interactively.

Thanks,

Dongwook

 Hi,

I wonder how others manage this situation because deamons in /etc/init.d is excercuted by root. So I cannot run in /etc/init.d/elogd when the system starts up.

What do you think?

Thanks,

Dongwook

Now I realized that it is not a problem in /etc/init.d, but deamon itself.

When I run the following command as a root, it didn't run

/mnt/wd500/jnj/products/elog/sbin/elogd -D -c /mnt/wd500/jnj/products/elog/elog/elogd.cfg

But, it runs when I did as a user.

I really don't understand this strange behavior.

Thanks,

 I too am having issues installing on Mac OS X 10.9.1. I changed CFLAGS in makefile to;

CFLAGS += -O3 -funroll-loops -fomit-frame-pointer -W -Wall -D_FORTIFY_SOURCE=0

I get many lines of errors like this when I run make;

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/openssl/ssl.h:1491:6: note: 'SSL_accept' declared here

int     SSL_accept(SSL *ssl) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;

        ^

src/elogd.c:28809:19: warning: 'SSL_set_fd' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]

                  SSL_set_fd(ka_ssl_con[i_min], ka_sock[i_min]);

                  ^

After I moved an item from one logbook to another one I cannot reply on this item anymore.

When the submit button is clicked it returns: Submit not allowed

This eLog server running Linux is sync'd with an server running Windows XP.

On the windows server the funcionality is working perfect(so no Submit is not allowed on a reply)

First, thank you so much for elog;
after using it for about 3 years, it has proven really handy and reliable.

When there is a very long URL in a message in "plain" encoding,
and this message is displayed in a list of messages,
a very long scrollbar appears at the bottom (same "scroll width" as the URL)
and some tabs and and dropdowns (filters) are unreachable without scrolling.

This does not happen if

• the message is displayed in single message page
• the message has a ELCode encoding

The exact version used is
0b9f7ed0 Merge branch 'develop'

There are no relevant instructions in elog.css for .messagelist,
and I did not find any obvious fix in the source code.

Hey,

the syntax for creating links to other elog entries has a small issue in the HTML editor. The link will not be created properly if there are whitespaces in the name of the logbook. Using ELCode (or in a simple attribute field) the whitespaces can be replaced by "+", but this does not work in the HTML editor. The work-around would be to use ELCode mark-up instead of HTML.

Example 1 (this should work): elog:Contributions/47

Example 2 (this will not work): elog:Config+Examples/11

Example 3 (will also not work): elog:Config%20Examples/11

Right now a Draft shows a red error indication, that the entry is currently a draft. For the CSS styling it uses the HTML class="errormsg". The same class is also used if an entry does not exist.

Would it be possible for the draft version to use a different HTML class (for example class="draftmsg")? It can also use the same visual style (or making it yellow would probably also work)

The reason is that the py_elog Interface uses the class="errormsg" to determine if an entry does not exist ( https://github.com/paulscherrerinstitute/py_elog/blob/master/elog/logbook.py#L394 ) and refuses to return the content for this entry. One could possibly fix that also on the py_elog part, but it would probably at least require parsing of actual text (which might make problems for translated pages). Alternativley one could also look for the edit button, but maybe a small change on the elog server side is the simplest solution to this problem?