Dear all.

I am running elog 

elogd 3.1.4 , revision ead6bbc6

on Macosx Mojave

Darwin arpg-serv.ing2.uniroma1.it 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64

I managed to compile and run without problems the elog source code.

I can run it and have it properly displayed at boot time. After the server boot, for few hours, I have the elog ready at http://arpg-serv.ing2.uniroma1.it/elog  but then, after few hours.. I get that the service stops and the elog is no longer accessible.

So far I was able to track down the problems only to the 

/var/log/system.log

file in which I find a not useful error message:

Eg: Apr 23 14:00:46 arpg-serv com.apple.xpc.launchd[1] (ch.psi.elogd[85248]): Service exited with abnormal code: 1

I do not know I can I debug this nor why the code runs for few hours without problems... I just re-downloaded the code from scratch today, unloaded and then re-loaded the daemon but still it fails with the same error.

I am sure that I can get it running again for few hours by re-booting. But I want to understand the source of the problem.. Anyone can be of help on this long standing issue?

Thanks

This kind of behavior we typically see if some elog entry is corrupt. After a few hours you might access this corrupt entry by accident, and then the server stops. If you see however this behavior on a fresh logbook with no corrupt entries, then the problem must lie somewhere else.

Do you see the same problem running under linux?

Do you see the same problem if you run elogd interactively (not through launchd)?

If you run elogd inside a debugger (like gdb or lldb), what does the debugger tell you when it crashes and you show the stack frames? Make sure to compile with -O0 and -g flags to include debug information in the executable.

Stefan 

Thanks for the prompt feedback.

a) I confirm that the problems shows up also when running interactively the elog through  elogd -p 8080

b) I am trying to catch the exit using lldb on the mac machine. I will be able to give you some feedback on that I hope in the next week (not easy access to the server)

c) What is the clean - recommended way to port everything on the linux machine and debug? I would do the following: download/install elog on a linux server, 'copy' all that now lives under /usr/local/elog on the mac one on the linux server, start the elog... is this ok? or there's anything else that I need to copy from the mac server to be sure to have the same environment?

Thanks again.

Alessio

What you recommend is enough. Just make sure to compile elogd with the flags mentioned before, and when you get the segment violation, do a stack trace inside the debugger to learn where the fault happend. Maybe also print the contents of some variables at the current location.

Stefan

I was finally able to catch the crash.

I paste below the info provided by lldb..

It seems that it has something to do with the 'first' logbook that contains 115 entries and is displayed in 6 pages.

But I do not know how to go any further... 

Any idea on how to debug from now on?

Thanks!

2019-04-30 12:32:27.602782+0200 elogd[19289:1908166] detected source and destination buffer overlap

Process 19289 stopped

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT

    frame #0: 0x00007fff7a1272c6 libsystem_kernel.dylib`__pthread_kill + 10

libsystem_kernel.dylib`__pthread_kill:

->  0x7fff7a1272c6 <+10>: jae    0x7fff7a1272d0            ; <+20>

    0x7fff7a1272c8 <+12>: movq   %rax, %rdi

    0x7fff7a1272cb <+15>: jmp    0x7fff7a121457            ; cerror_nocancel

    0x7fff7a1272d0 <+20>: retq   

Target 0: (elogd) stopped.

(lldb) thread backtrace all

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT

  * frame #0: 0x00007fff7a1272c6 libsystem_kernel.dylib`__pthread_kill + 10

    frame #1: 0x00007fff7a1dcbf1 libsystem_pthread.dylib`pthread_kill + 284

    frame #2: 0x00007fff7a0916a6 libsystem_c.dylib`abort + 127

    frame #3: 0x00007fff7a091819 libsystem_c.dylib`abort_report_np + 177

    frame #4: 0x00007fff7a0b5cb1 libsystem_c.dylib`__chk_fail + 48

    frame #5: 0x00007fff7a0b5cc1 libsystem_c.dylib`__chk_fail_overlap + 16

    frame #6: 0x00007fff7a0b5ce3 libsystem_c.dylib`__chk_overlap + 34

    frame #7: 0x00007fff7a0b5d39 libsystem_c.dylib`__strlcpy_chk + 58

    frame #8: 0x000000010006a7ac elogd`build_ref(ref="page6?&sort=Subject", size=256, mode="full", expand="", attach="", new_entries="") at elogd.c:19021:7

    frame #9: 0x000000010006aaf6 elogd`show_page_filters(lbs=0x0000000102804308, n_msg=115, page_n=6, mode_commands=YES, mode="Summary") at elogd.c:19072:10

    frame #10: 0x00000001000536b8 elogd`show_elog_list(lbs=0x0000000102804308, past_n=0, last_n=0, page_n=6, default_page=NO, info=0x0000000000000000) at elogd.c:21506:10

    frame #11: 0x000000010008ee58 elogd`interprete(lbook="first", path="") at elogd.c:28543:7

    frame #12: 0x000000010008f096 elogd`decode_get(logbook="first", string="?id") at elogd.c:28583:4

    frame #13: 0x00000001000937fd elogd`process_http_request(request="GET /first?id=108&sort=Subject", i_conn=0) at elogd.c:29361:7

    frame #14: 0x0000000100097744 elogd`server_loop at elogd.c:30375:20

    frame #15: 0x000000010009a073 elogd`main(argc=3, argv=0x00007ffeefbffc20) at elogd.c:31403:4

    frame #16: 0x00007fff79fec3d5 libdyld.dylib`start + 1

Actually it is a little bit more difficult than that.

I have restarted elogd and got a crash but this time it seems related to a different logbook...

Below the stack trace..

Alessio

2019-04-30 13:58:52.408845+0200 elogd[22152:2009063] detected source and destination buffer overlap

Process 22152 stopped

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT

    frame #0: 0x00007fff7a1272c6 libsystem_kernel.dylib`__pthread_kill + 10

libsystem_kernel.dylib`__pthread_kill:

->  0x7fff7a1272c6 <+10>: jae    0x7fff7a1272d0            ; <+20>

    0x7fff7a1272c8 <+12>: movq   %rax, %rdi

    0x7fff7a1272cb <+15>: jmp    0x7fff7a121457            ; cerror_nocancel

    0x7fff7a1272d0 <+20>: retq   

Target 0: (elogd) stopped.

(lldb) 

error: No auto repeat.

(lldb) thread backtrace all

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT

  * frame #0: 0x00007fff7a1272c6 libsystem_kernel.dylib`__pthread_kill + 10

    frame #1: 0x00007fff7a1dcbf1 libsystem_pthread.dylib`pthread_kill + 284

    frame #2: 0x00007fff7a0916a6 libsystem_c.dylib`abort + 127

    frame #3: 0x00007fff7a091819 libsystem_c.dylib`abort_report_np + 177

    frame #4: 0x00007fff7a0b5cb1 libsystem_c.dylib`__chk_fail + 48

    frame #5: 0x00007fff7a0b5cc1 libsystem_c.dylib`__chk_fail_overlap + 16

    frame #6: 0x00007fff7a0b5ce3 libsystem_c.dylib`__chk_overlap + 34

    frame #7: 0x00007fff7a0b5d39 libsystem_c.dylib`__strlcpy_chk + 58

    frame #8: 0x00000001000684e3 elogd`subst_param(str="&Type=%5EInfo%24", size=1500, param="last", value="") at elogd.c:18712:7

    frame #9: 0x000000010004bbaa elogd`show_elog_list(lbs=0x0000000103801008, past_n=0, last_n=0, page_n=0, default_page=YES, info=0x0000000000000000) at elogd.c:20183:7

    frame #10: 0x000000010008ee58 elogd`interprete(lbook="FOOTGsi2019", path="") at elogd.c:28543:7

    frame #11: 0x000000010008f096 elogd`decode_get(logbook="FOOTGsi2019", string="?last") at elogd.c:28583:4

    frame #12: 0x00000001000937fd elogd`process_http_request(request="GET /FOOTGsi2019/?last=_all_&Type=%5EInfo%24", i_conn=2) at elogd.c:29361:7

    frame #13: 0x0000000100097744 elogd`server_loop at elogd.c:30375:20

    frame #14: 0x000000010009a073 elogd`main(argc=3, argv=0x00007ffeefbffc20) at elogd.c:31403:4

    frame #15: 0x00007fff79fec3d5 libdyld.dylib`start + 1

Ok, that helped. It looks to me that the strlcpy() function from MacOSC does not like overlapping stings as parameters. Funny that this does not happen on my Mac (Mojave 10.14.4). I fixed the two cases you reported (lines 18712 and 19021) and committed the changes to bitbucket, from where you can pull and test it again (see https://elog.psi.ch/elog/download.html for instructions). If it happens again, please report the line number in elogd.c like here (where it is 19021:7):

frame #8: 0x000000010006a7ac elogd`build_ref(ref="page6?&sort=Subject", size=256, mode="full", expand="", attach="", new_entries="") at elogd.c:19021:7

Good luck!

Stefan

Thanks a lot for providing a quick fix!

The elog is now happily running since two days without problems :)

I will get back to you in case anything else shows up.

Thanks a lot again.

Hi, I was wondering if this is possible. I've tried to sort on anything other than the first few fields and although the screen refreshes like it is 'doing something', it does NOT sort. Sometimes it will take me to the last page of my data, but still no sorting. I use Debian Linux verson of Elog. There have been no other issues. I need to figure out how to do this without parsing it to another program first. Thanks again for this wonderful program :)

John

Sorting does work fine, if you do it correctly. From your post I cannot even guess what you've tried - let alone tell you what you did wrong.

Please post your config, some example entries and a description of what you've tried, what you expected to happen and what actually happened. Screenshots are often very useful as well.

Hi Andrea and thank you soo much  for your kind and prompt reply! I believe the issue will be solved as I have the information I need to proceed. I was just wanting to verify that sorting indeed is alloud on ALL fields.  I cannot send the exact config as it is a work project, but I can replicate with fake fields and data if necessary in the future. I believe my errors are because I am either using field names which are 'special' to the system, or some other limitation. I will try compiling and see if that helps. 

John

How can I exclude the access of a number of users in one (out of two) logbooks running in the same server and URL?

You have a look here: elog:68936

submissions via the elog - program can overwrite entries even if the user has no edit rights

Since there's no answer to that.
I am the only one with the problem? Did I just configure something wrong?
Thanks Heinz

There are two ways:

1) Use different password files for different logbooks. Each password file contains only those users which have access to that logbook.

2) Use "Login user = <usr list>" to restrict access to certain users in that list.

Stefan

Thanks for the answer. The real problem is that you can overwrite existing entries even if you have set an entry to "read only", i.e. you have forbidden further editing.

Heinz

There is no "read only" flag. Please describe what you exactly did. Probably you want "Restrict edit time" for that.

Stefan

Sorry, 

I meant "read only" by using "Restrict edit time" settings. e.g.

Restrict edit time = 24

I understand this to mean that an entry should not be able to be modified after 24 hours.

Heinz

So you are telling me that "Restrict edit time" is not working correctly? In order to fix any problem, I have to reproduce it. Can you post a minimel elogd.cfg file with which I can reproduce the problem?

Stefan

I ask my users where they had the problems and then create a demo for testing.
Thanks Heinz

Stefan, will send the info off this forum.

Heinz

Ok, I found the issue. The "Restrict edit time" is only checked when one clicks on "Edit" in the browser. The elog command line tool does not really an edit, but just submits an entry with an (old) ID. I added a check also for that case so now it should work. The commit is in git.

Stefan

We're running elogd behind an apache proxy server, with Authentication = Webserver. We have top groups configured, but a single shared password file.

If a user is looking at a particular logbook and goes to the Config link, they are presented with a list of checkboxes for email subscription to logbooks in that top group.  Clicking "Save" will remove all email subscriptions from all other top groups.

Is there a workaround to this issue?

EDIT: Manually adding an entry for different logbooks in the password file gets clobbered the next time the user logs in.

Top groups should use separate password files, otherwise things can mess up.

Stefan

Hi and thanx for such a wonderful program! I was wondering how I might edit, change or add to the landing pages. In other words the first pages that show up (or any for that matter) when you login to a book. I can view the code ok in my browser using that function, but when I search for the actual page and it's locale, I cannot find it. Is it created on the fly by the server? If so, how can I change them.. as I want to add for instance javascripts to manipulate the pages and data more, without actually loosing the main essence of the program (log books). Thanx

Well I answered part of my own question already.. I can have a start page different from what is default, and I can edit the orginal one by simply copying it and modifiying it to my hearts desire. I still have isues  after making menu selections from that page tho,  when the program (server) takes me to a site called  for example: ../forum/index.html?cmd=Config. I cannot find out how to prevent or modify this behaviour. I am supposing tho, that because I am using my own original index.html (start page), that the program is not modifying it (on the fly), like it does with the oringal web pages?  I am also still currious if the program does indeed create/modify pages on the fly, and if it does, where does it store them on my hard drive (or is it only put in memory temporaly?). Thanx again :)

Per default, all pages are created dynamically by elogd directly from its C code. So nothing to change easily except hacking the code. There is one exception which is the start page you found already. To change any other page, you have to modify the C code. There is one more (dirty) trick: You can sneak in JavaScript code on every page via the "bottom text" option. This code can then modify the DOM tree and changes pages, but you need to program this in JavaScript.

Stefan

Wow Stefan thanks for your kind reply.  This gives me a reason to finally pickup JavaScript, which I am finding both easy and fun, esepcially with all the modules/coding out there already, which makes things easier to do while learning it! I will let you know as I progress on my 'top secret' hack of your masterpiece ;)

As the title says, we have our elog running behind an Apache proxy that is also providing authentication. We also have top groups enabled.  The first time a user views a top group page with a fresh browser cache, the index is delivered, but requests for elog.css and lock.png are returned with http 302 with location set to the elog root.  (I.e., if the server is proxied under server.example.com/logs,  the first request for server.example.com/logs/TopGroup1/elog.css returns a 302 with location set to server.example.com/logs// ). 

Any subsequent visits return the files fine. The attached screenshot shows the network requests in chrome. 

Is this a proxy configuration issue, something we've set wrong in elog, ??

Looks more like a bug to me. Will investigate.

Stefan

Dear users,

we started an elog serveur (using ssl) and open to the world which is working fine.

However I am trying to access it via the command line client, from a computer that uses a proxy to connect to internet.

The environnment variable are set :

declare -x ftp_proxy="ftp://myproxy:3128/"
declare -x http_proxy="http://myproxy:3128/"
declare -x https_proxy="https://myproxy:3128/"
declare -x socks_proxy="socks://myproxy:3128/"
 

but when I try to connect

elog  -h myelog -p 443 -l lognote -s 1 -u username passwd  -w last

I have the following message :

Cannot connect to host myelog, port 44

How should I proceed ?

Best regards

JG

:

The "elog" client does unfortunately not support proxies. You could however achieve the same with the "curl" tool. Have a look at elog:68597

Stefan