add a little function--go to the specified page number, posted by Xuan Wu on Tue May 14 09:40:58 2019 
|
Hi all,
I added an input widget for pagination. I'd like to share it here, maybe someone needs. If there are many pages, specifying the page number will be useful.
The picture and patch code are in the attachment
Regards,
Xuan |
Shell execute, posted by Alan Grant on Tue May 14 06:07:07 2019
|
I have the line in my elog config to run a Powershell script when submitting a New entry. I just send an email as a test:
Execute New = "Powershell.exe -ExecutionPolicy Bypass D:\SendEmail.ps1"
Fyi, the Powershell statement itself (Send-MailMessage -From 'MeterElog@winnipeg.ca' -To 'alangrant@mts.net' -Subject 'New meter entry' -Body 'TEST' -Priority High -DeliveryNotificationOption OnSuccess, OnFailure -SmtpServer 'citygw') works fine and the email is received when running it from the Powershell ISE app directly from the same elog vm server but not from within Elog with the above statement.
I'd like to first confirm that the syntax of the line Execute New = is correct, ie, double quoting the entire command. Can anyone please confirm. |
|
Execute attribute, posted by Alan Grant on Fri May 10 04:34:36 2019
|
Apart from an inline shell command that can be run with the Execute attribute, is it possible to run an external script file? I would like to run a Powershell script with the Elog attribute data parameters passed to it upon Submit New entry. |
Re: Execute attribute, posted by Stefan Ritt on Fri May 10 08:19:08 2019
|
I don't understand your question. There is no "inline" vs. "external" script. Using the "execute new = <command>", you run a script on the server side. Can be powershell under Windows or bash/csh under Linux. I remember however that there has been issues under recent windows in passing parameters to the shell. Linux certainly works fine, we usse it all the time.
| Alan Grant wrote: |
|
Apart from an inline shell command that can be run with the Execute attribute, is it possible to run an external script file? I would like to run a Powershell script with the Elog attribute data parameters passed to it upon Submit New entry.
|
|
|
Re: Execute attribute, posted by Alan Grant on Fri May 10 15:01:52 2019
|
I think it was just a matter of my specific interepretation of the documentation, ie: using native OS shell commands vs any script language file containing shell commands or any app for that matter. Nevertheless I think you've answered my questiuon so it's all good. Thanks Stefan.
| Stefan Ritt wrote: |
|
I don't understand your question. There is no "inline" vs. "external" script. Using the "execute new = <command>", you run a script on the server side. Can be powershell under Windows or bash/csh under Linux. I remember however that there has been issues under recent windows in passing parameters to the shell. Linux certainly works fine, we usse it all the time.
| Alan Grant wrote: |
|
Apart from an inline shell command that can be run with the Execute attribute, is it possible to run an external script file? I would like to run a Powershell script with the Elog attribute data parameters passed to it upon Submit New entry.
|
|
|
Does there is a way to no the $message_id when creating a new submission, posted by Lagarde on Thu May 9 13:34:55 2019
|
Hello,
I would like to know if it's possible to know the message_id of when creating a new entry in elog ?
I would like to do something like this Preset text = $message_id
Thx;
|
|
Re: Does there is a way to no the $message_id when creating a new submission, posted by Stefan Ritt on Thu May 9 16:42:13 2019
|
No, the message ID gets assigned only when you submit the entry.
Stefan
| Lagarde wrote: |
|
Hello,
I would like to know if it's possible to know the message_id of when creating a new entry in elog ?
I would like to do something like this Preset text = $message_id
Thx;
|
|
|
Last default = <n>, posted by Alan Grant on Mon Apr 29 02:41:15 2019
|
According to the doc on the setting "Last default = <n>" it is intended to restrict Quick Filter searches to the last (n) days of entries, however when I add "Last default = 28" to config it still returns entries far older then 28 days when using the filter search. Am I misunderstanding, or implementing it wrong? We must restrict searches through QF to reduce load.
A couple other side questions which are related:
The doc on this setting says: "Last default = <n>
Some logbooks are very big ans searching through all entries with quick filter can be time consuming. This option sets a default value for the Date quick filter, so that by default only the <n> days are displayed." ...... I'm assuming that by saying "only the <n> days are displayed" that it has actually only searched <n> days ................ vs seaching ALL the logbooks but only displaying <n> days. Please confirm.
Also, why wouldn't the "28" days spec display in the Select Period box beside the Quick Filters? Otherwise it appears to me to be a separate and conflicting item. Best regards! |
|
Re: Last default = <n>, posted by Stefan Ritt on Mon Apr 29 13:12:56 2019
|
Indeed the description of the "Last default = <n>" option is not clear. I just updated that. If you have a quick filter "Date", then you have different options there like "Last day", "Last 3 days", "Last week", "Last month", "Last 3 months", "Last 6 months", "Last year". Each of these options has an underlying number of days, which are 1, 3, 7, 31, 92, 182, 364. In the "Last default = <n>" option you can only choose one of these seven options. Then this option is selected by default and the filter is applied accordingly. This lets you still change the date filter to a longer time period for example, but then with the penalty of longer search times.
So what you need is "Last default = 31" instead of 28 and it should work.
Stefan
| Alan Grant wrote: |
|
According to the doc on the setting "Last default = <n>" it is intended to restrict Quick Filter searches to the last (n) days of entries, however when I add "Last default = 28" to config it still returns entries far older then 28 days when using the filter search. Am I misunderstanding, or implementing it wrong? We must restrict searches through QF to reduce load.
A couple other side questions which are related:
The doc on this setting says: "Last default = <n>
Some logbooks are very big ans searching through all entries with quick filter can be time consuming. This option sets a default value for the Date quick filter, so that by default only the <n> days are displayed." ...... I'm assuming that by saying "only the <n> days are displayed" that it has actually only searched <n> days ................ vs seaching ALL the logbooks but only displaying <n> days. Please confirm.
Also, why wouldn't the "28" days spec display in the Select Period box beside the Quick Filters? Otherwise it appears to me to be a separate and conflicting item. Best regards!
|
|
|
Re: Last default = <n>, posted by Alan Grant on Mon Apr 29 17:48:13 2019
|
I just changed to Last default = 31 and even restarted elogd.exe but it still finds a given string older than 31 days. Also the default Select Period box value next to the QF's remains at All Entries. My understanding is it shoud behave like Find, where Show Last Default = 31 should default the display to Month, and also only search within the last month of entries.
| Stefan Ritt wrote: |
|
Indeed the description of the "Last default = <n>" option is not clear. I just updated that. If you have a quick filter "Date", then you have different options there like "Last day", "Last 3 days", "Last week", "Last month", "Last 3 months", "Last 6 months", "Last year". Each of these options has an underlying number of days, which are 1, 3, 7, 31, 92, 182, 364. In the "Last default = <n>" option you can only choose one of these seven options. Then this option is selected by default and the filter is applied accordingly. This lets you still change the date filter to a longer time period for example, but then with the penalty of longer search times.
So what you need is "Last default = 31" instead of 28 and it should work.
Stefan
| Alan Grant wrote: |
|
According to the doc on the setting "Last default = <n>" it is intended to restrict Quick Filter searches to the last (n) days of entries, however when I add "Last default = 28" to config it still returns entries far older then 28 days when using the filter search. Am I misunderstanding, or implementing it wrong? We must restrict searches through QF to reduce load.
A couple other side questions which are related:
The doc on this setting says: "Last default = <n>
Some logbooks are very big ans searching through all entries with quick filter can be time consuming. This option sets a default value for the Date quick filter, so that by default only the <n> days are displayed." ...... I'm assuming that by saying "only the <n> days are displayed" that it has actually only searched <n> days ................ vs seaching ALL the logbooks but only displaying <n> days. Please confirm.
Also, why wouldn't the "28" days spec display in the Select Period box beside the Quick Filters? Otherwise it appears to me to be a separate and conflicting item. Best regards!
|
|
|
|
Re: Last default = <n>, posted by Stefan Ritt on Wed May 1 11:06:04 2019
|
It works for me. Have you tried other values (1, 3, 7, ..)? The key is that the quick filter changes to "Last month". If it does not, there must be some trivial error, like type in elogd.cfg, you modify the wrong logbook, have a very old version of elog etc.
Stefan
| Alan Grant wrote: |
|
I just changed to Last default = 31 and even restarted elogd.exe but it still finds a given string older than 31 days. Also the default Select Period box value next to the QF's remains at All Entries. My understanding is it shoud behave like Find, where Show Last Default = 31 should default the display to Month, and also only search within the last month of entries.
| Stefan Ritt wrote: |
|
Indeed the description of the "Last default = <n>" option is not clear. I just updated that. If you have a quick filter "Date", then you have different options there like "Last day", "Last 3 days", "Last week", "Last month", "Last 3 months", "Last 6 months", "Last year". Each of these options has an underlying number of days, which are 1, 3, 7, 31, 92, 182, 364. In the "Last default = <n>" option you can only choose one of these seven options. Then this option is selected by default and the filter is applied accordingly. This lets you still change the date filter to a longer time period for example, but then with the penalty of longer search times.
So what you need is "Last default = 31" instead of 28 and it should work.
Stefan
| Alan Grant wrote: |
|
According to the doc on the setting "Last default = <n>" it is intended to restrict Quick Filter searches to the last (n) days of entries, however when I add "Last default = 28" to config it still returns entries far older then 28 days when using the filter search. Am I misunderstanding, or implementing it wrong? We must restrict searches through QF to reduce load.
A couple other side questions which are related:
The doc on this setting says: "Last default = <n>
Some logbooks are very big ans searching through all entries with quick filter can be time consuming. This option sets a default value for the Date quick filter, so that by default only the <n> days are displayed." ...... I'm assuming that by saying "only the <n> days are displayed" that it has actually only searched <n> days ................ vs seaching ALL the logbooks but only displaying <n> days. Please confirm.
Also, why wouldn't the "28" days spec display in the Select Period box beside the Quick Filters? Otherwise it appears to me to be a separate and conflicting item. Best regards!
|
|
|
|
|
Re: Last default = <n>, posted by Stefan Ritt on Wed May 1 11:08:10 2019
|
You say "Show Last Default = 31". This options applies only to the "Find" page, the option "Last Default = 31" works for the quick filter. Probably you have to change "Show Last Default" to "Last Default".
Stefan
| Alan Grant wrote: |
|
I just changed to Last default = 31 and even restarted elogd.exe but it still finds a given string older than 31 days. Also the default Select Period box value next to the QF's remains at All Entries. My understanding is it shoud behave like Find, where Show Last Default = 31 should default the display to Month, and also only search within the last month of entries.
| Stefan Ritt wrote: |
|
Indeed the description of the "Last default = <n>" option is not clear. I just updated that. If you have a quick filter "Date", then you have different options there like "Last day", "Last 3 days", "Last week", "Last month", "Last 3 months", "Last 6 months", "Last year". Each of these options has an underlying number of days, which are 1, 3, 7, 31, 92, 182, 364. In the "Last default = <n>" option you can only choose one of these seven options. Then this option is selected by default and the filter is applied accordingly. This lets you still change the date filter to a longer time period for example, but then with the penalty of longer search times.
So what you need is "Last default = 31" instead of 28 and it should work.
Stefan
| Alan Grant wrote: |
|
According to the doc on the setting "Last default = <n>" it is intended to restrict Quick Filter searches to the last (n) days of entries, however when I add "Last default = 28" to config it still returns entries far older then 28 days when using the filter search. Am I misunderstanding, or implementing it wrong? We must restrict searches through QF to reduce load.
A couple other side questions which are related:
The doc on this setting says: "Last default = <n>
Some logbooks are very big ans searching through all entries with quick filter can be time consuming. This option sets a default value for the Date quick filter, so that by default only the <n> days are displayed." ...... I'm assuming that by saying "only the <n> days are displayed" that it has actually only searched <n> days ................ vs seaching ALL the logbooks but only displaying <n> days. Please confirm.
Also, why wouldn't the "28" days spec display in the Select Period box beside the Quick Filters? Otherwise it appears to me to be a separate and conflicting item. Best regards!
|
|
|
|
|
Re: Last default = <n>, posted by Alan Grant on Wed May 1 15:28:41 2019
|
I was just referring to "Show last default" (under Find) as a parallel example of how I assume "Last default" should function on the List page.
I also tried values 3 and 7 but "All entries" still displays in the "List period" box. A restart of elogd makes no difference.
Elog v3.1.2, Windows Server 2016 Std, 64 bit.
If you don't mind, I have attached my elogd.cfg. I realize you are quite busy so there is no rush. Thanks.
PS: I just noticed that the attached elogd.cfg indicates version 2.9.2 but it's actually 3.1.2 I have installed (just forgot to update the Welcome line).
| Stefan Ritt wrote: |
|
You say "Show Last Default = 31". This options applies only to the "Find" page, the option "Last Default = 31" works for the quick filter. Probably you have to change "Show Last Default" to "Last Default".
Stefan
| Alan Grant wrote: |
|
I just changed to Last default = 31 and even restarted elogd.exe but it still finds a given string older than 31 days. Also the default Select Period box value next to the QF's remains at All Entries. My understanding is it shoud behave like Find, where Show Last Default = 31 should default the display to Month, and also only search within the last month of entries.
| Stefan Ritt wrote: |
|
Indeed the description of the "Last default = <n>" option is not clear. I just updated that. If you have a quick filter "Date", then you have different options there like "Last day", "Last 3 days", "Last week", "Last month", "Last 3 months", "Last 6 months", "Last year". Each of these options has an underlying number of days, which are 1, 3, 7, 31, 92, 182, 364. In the "Last default = <n>" option you can only choose one of these seven options. Then this option is selected by default and the filter is applied accordingly. This lets you still change the date filter to a longer time period for example, but then with the penalty of longer search times.
So what you need is "Last default = 31" instead of 28 and it should work.
Stefan
| Alan Grant wrote: |
|
According to the doc on the setting "Last default = <n>" it is intended to restrict Quick Filter searches to the last (n) days of entries, however when I add "Last default = 28" to config it still returns entries far older then 28 days when using the filter search. Am I misunderstanding, or implementing it wrong? We must restrict searches through QF to reduce load.
A couple other side questions which are related:
The doc on this setting says: "Last default = <n>
Some logbooks are very big ans searching through all entries with quick filter can be time consuming. This option sets a default value for the Date quick filter, so that by default only the <n> days are displayed." ...... I'm assuming that by saying "only the <n> days are displayed" that it has actually only searched <n> days ................ vs seaching ALL the logbooks but only displaying <n> days. Please confirm.
Also, why wouldn't the "28" days spec display in the Select Period box beside the Quick Filters? Otherwise it appears to me to be a separate and conflicting item. Best regards!
|
|
|
|
|
|
Re: Last default = <n>, posted by Stefan Ritt on Fri May 3 15:50:39 2019
|
I just tried your elogd.cfg, and it works fine for me. So no idea what is wrong in your case.
Stefan |
|
Re: Last default = <n>, posted by Alan Grant on Fri May 3 16:02:33 2019
|
Ok thanks for taking the time to try it out. I definitely still show "All entries" in any case, so I will continue to try to resolve on my end and if I find the cause or solution I will share back on the forum.
First though, I noticed you ran 3.1.4 whereas I'm still on 3.1.2. I'm also on Windows Server 2016 and IE 11. Do you think any of that might make the difference?
| Stefan Ritt wrote: |
|
I just tried your elogd.cfg, and it works fine for me. So no idea what is wrong in your case.
Stefan
|
|
|
Re: Last default = <n>, posted by Stefan Ritt on Fri May 3 16:22:23 2019
|
Yes I always run the current version from bitbucket. I haven't touched that code for "last default" since a long time, so I don't expect the verison to make a difference. Unfortuantely I have not Windows Server or IE for testing.
| Alan Grant wrote: |
|
Ok thanks for taking the time to try it out. I definitely still show "All entries" in any case, so I will continue to try to resolve on my end and if I find the cause or solution I will share back on the forum.
First though, I noticed you ran 3.1.4 whereas I'm still on 3.1.2. I'm also on Windows Server 2016 and IE 11. Do you think any of that might make the difference?
| Stefan Ritt wrote: |
|
I just tried your elogd.cfg, and it works fine for me. So no idea what is wrong in your case.
Stefan
|
|
|
|
Re: Last default = <n>, posted by Alan Grant on Fri May 3 16:29:00 2019
|
Thanks again.
I noticed in the Change Log for 3.1.4 that there's a reference to something done with "Last default" in Sept 2018 so I think I will try to set up a Linux instance and try out 3.1.4. Regards.
Version 3.1.4, released September 26th, 2018
============================================
- Replaced sprintf by snprintf
- Changed midas.psi.ch to elog.psi.ch
- Fixed bug for redirect under two daisy-chained proxies
- Removed while(in_asend) which caused some browsers to block
- Implemented elogd.service for systemd daemon
- Implemented "max email attachment size"
- Limit max request size to 100 MB
- Allow ampersand in user names
- Added code to detect Unicode characters as HTML
- add "Email CSS URL" : use public copy of CSS for emails
- bugfix: replace hard-coded reference of "New" to loc("New")
- add "Subscription columns" : format list of logbooks for subscriptions in columns
- Added "interface" option
- Fixed crash on negative Content-Length in header
- Fixed "?npp=0" crash
- Added confirmation dialog before deleting an attachment
- Implemented "last default" to restrict quick filter display by default on the last n days
- Made header parsing case insensitive
- Switched to TLSv1_
| Stefan Ritt wrote: |
|
Yes I always run the current version from bitbucket. I haven't touched that code for "last default" since a long time, so I don't expect the verison to make a difference. Unfortuantely I have not Windows Server or IE for testing.
| Alan Grant wrote: |
|
Ok thanks for taking the time to try it out. I definitely still show "All entries" in any case, so I will continue to try to resolve on my end and if I find the cause or solution I will share back on the forum.
First though, I noticed you ran 3.1.4 whereas I'm still on 3.1.2. I'm also on Windows Server 2016 and IE 11. Do you think any of that might make the difference?
| Stefan Ritt wrote: |
|
I just tried your elogd.cfg, and it works fine for me. So no idea what is wrong in your case.
Stefan
|
|
|
|
|
Re: Last default = <n>, posted by Stefan Ritt on Fri May 3 16:48:47 2019
|
Indeed you're right (my memory is fading, argh). Please try 3.1.4.
Stefan
| Alan Grant wrote: |
|
Thanks again.
I noticed in the Change Log for 3.1.4 that there's a reference to something done with "Last default" in Sept 2018 so I think I will try to set up a Linux instance and try out 3.1.4. Regards.
Version 3.1.4, released September 26th, 2018
============================================
- Replaced sprintf by snprintf
- Changed midas.psi.ch to elog.psi.ch
- Fixed bug for redirect under two daisy-chained proxies
- Removed while(in_asend) which caused some browsers to block
- Implemented elogd.service for systemd daemon
- Implemented "max email attachment size"
- Limit max request size to 100 MB
- Allow ampersand in user names
- Added code to detect Unicode characters as HTML
- add "Email CSS URL" : use public copy of CSS for emails
- bugfix: replace hard-coded reference of "New" to loc("New")
- add "Subscription columns" : format list of logbooks for subscriptions in columns
- Added "interface" option
- Fixed crash on negative Content-Length in header
- Fixed "?npp=0" crash
- Added confirmation dialog before deleting an attachment
- Implemented "last default" to restrict quick filter display by default on the last n days
- Made header parsing case insensitive
- Switched to TLSv1_
| Stefan Ritt wrote: |
|
Yes I always run the current version from bitbucket. I haven't touched that code for "last default" since a long time, so I don't expect the verison to make a difference. Unfortuantely I have not Windows Server or IE for testing.
| Alan Grant wrote: |
|
Ok thanks for taking the time to try it out. I definitely still show "All entries" in any case, so I will continue to try to resolve on my end and if I find the cause or solution I will share back on the forum.
First though, I noticed you ran 3.1.4 whereas I'm still on 3.1.2. I'm also on Windows Server 2016 and IE 11. Do you think any of that might make the difference?
| Stefan Ritt wrote: |
|
I just tried your elogd.cfg, and it works fine for me. So no idea what is wrong in your case.
Stefan
|
|
|
|
|
elogd Service exited with abnormal code: 1, posted by Alessio Sarti on Tue Apr 23 14:06:36 2019
|
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 |
|
Re: elogd Service exited with abnormal code: 1, posted by Stefan Ritt on Tue Apr 23 14:26:51 2019
|
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
| Alessio Sarti wrote: |
|
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
|
|
|
Re: elogd Service exited with abnormal code: 1, posted by Alessio Sarti on Thu Apr 25 11:16:06 2019
|
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
| Stefan Ritt wrote: |
|
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
| Alessio Sarti wrote: |
|
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
|
|
|
|
Re: elogd Service exited with abnormal code: 1, posted by Stefan Ritt on Thu Apr 25 11:27:21 2019
|
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
| Alessio Sarti wrote: |
|
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
| Stefan Ritt wrote: |
|
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
| Alessio Sarti wrote: |
|
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
|
|
|
|
|
Re: elogd Service exited with abnormal code: 1, posted by Alessio Sarti on Tue Apr 30 12:47:46 2019
|
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
| Stefan Ritt wrote: |
|
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
| Alessio Sarti wrote: |
|
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
| Stefan Ritt wrote: |
|
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
| Alessio Sarti wrote: |
|
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
|
|
|
|
|
|
Re: elogd Service exited with abnormal code: 1, posted by Alessio Sarti on Tue Apr 30 14:07:52 2019
|
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
| Alessio Sarti wrote: |
|
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
| Stefan Ritt wrote: |
|
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
| Alessio Sarti wrote: |
|
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
| Stefan Ritt wrote: |
|
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
| Alessio Sarti wrote: |
|
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
|
|
|
|
|
|
|
Re: elogd Service exited with abnormal code: 1, posted by Stefan Ritt on Wed May 1 10:59:59 2019
|
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 |
|
Re: elogd Service exited with abnormal code: 1, posted by Alessio Sarti on Thu May 2 09:47:41 2019
|
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.
| Stefan Ritt wrote: |
|
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
|
|
|
How to sort on any field?, posted by John on Tue Apr 30 05:52:44 2019
|
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 |
|
Re: How to sort on any field?, posted by Andreas Luedeke on Tue Apr 30 14:20:34 2019
|
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.
| John wrote: |
|
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
|
|
Re: How to sort on any field?, posted by John on Tue Apr 30 19:07:17 2019
|
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
| Andreas Luedeke wrote: |
|
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.
| John wrote: |
|
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
|
|
|
|
exclude access to a number of users in one logbook, posted by Nikolas Patronis on Wed Apr 24 09:15:26 2019
|
How can I exclude the access of a number of users in one (out of two) logbooks running in the same server and URL? |
|
Re: exclude access to a number of users in one logbook, posted by Stefan Ritt on Tue Apr 30 09:34:52 2019
|
You have a look here: elog:68936
| Nikolas Patronis wrote: |
|
How can I exclude the access of a number of users in one (out of two) logbooks running in the same server and URL?
|
|
|