Dear Stefano,

Try the entry I wrote some time ago elog:68655

David.


> Dear expert,
>   I'm running the latest git version of elog ELOG V3.1.4-395e101a on ubuntu 20.04.2.
> I'm experiencing frequent hangs of the elog server: the status is always reported as running, but the web server is not responding.
> The only hint I have of something strange is that the elogd process is using a lot of CPU (50-100%), the log do not show anything suspect 
> as far as I can see.
> 
> Has anyone experienced something similar or has any idea how can I start to debug the problem?
> 
> Sorry for lack of many information, but I don't know what to look at.
> 
> Thanks in advance
>   Stefano

The way to do this is to ensure that the date of the entry is in the future.  As a hard -core linux (ab)user of elog, I create an entry, then dive into the yymmdda.log files, and edit it so that the date at the top of the entry is, for example, Sat, 31 Dec 2022 23:59:59.  Then, that entry will remain at the top of the listings until the New Year.  I do this very thing for the very same reason, i.e. to keep one entry at the top of the listings until after a certain date.

It may be that if you have "date of entry" field and sort by that, you could set the date of entry in the future.  I've not tried that.

The same effect could be done by adjusting the computer/server's date to the future, make the entry and then reset back to the present, but that may well be unpopular and impractical.  On a single computer, I have done this, although I then changed to editing the yymmdda.log file directly.

I am rather with John on this.

I deliberately stopped contributing to Wikipedia years ago after I added an observation to an entry.  That is, a piece of what could be called original research.  It was shot down in flames for being precisely that: original research.    From what I read in the Draft:Elog and the Talk section,  I think that the same issue in some guise or other will come up.  All of us use and love Elog - I think I use it for all of the listed purposes - but apart from being in the Debian distro (which I did not know about) there is very little published primary sources.  Mind you, the quality of publications as primary sources can be questioned, I can bore on with several examples.  

Has anyone ever published a paper citing their filing cabinet organisation?  Elog's obviously different, but has the same problem when it comes to citations.  It is a utility, a very useful one, but the sort of utility that might just make an aside in a paper these days.  If we were in the 1980s and (hypothetically) Elog was available and as functional, that would probably make it the subject in computer research papers and magazines. 

David.

In my case, I had a number of attributes which had a varied prefix.  For example, "progressed" , which could have no prefix, or prefix "I", "To be", "Strongly", "Seriously"... and that was true (the same prefixes, or at least many of them) for a number of attributes.  Splitting them into two groups, the prefixes and the action, allowed me to gain more actual attributes without having to recompile.  Suitable change in the elog config file will also make this easy to follow in how the entries are shown in threaded or full display modes.  In your case suffixes may be better, but I hope you get the point.

Although I have done a (linux) recompile in the past, v2.9 something, 120 attributes seemed not to affect things.

Or what about the "ticket number" feature?  Every new entry  thread (sorry, confusing terminology on my part) would increment the ticket number by one, and there is no limit as far as I am aware.  This is all explained in the elogd configuration documentation.  

As for my suggestion earlier, now I'm at my computer with working elog. I think that the following four lines (three I guess already there but need alteration for this) need to appear in your elogd.conf file.  The first three should also include any other thing you need to display etc.  I've cut this down to the bear bones, and ... means anything else you want to add. 

Attributes = Die, Organisation, ...
List display = Die, Organisation. ...
Thread display = $Die: $Organisation ...
Preset Die = D_#####

Now the first time you run this, it will give D_00001.  You can edit that to D_00100 and it will increment from there.  You may wish to have two types of user, those who can start a new thread, such as yourself, and others who can contribute but not start a new thread / new Die discussion.

Now it may be that the attribute name you gave D_001 etc can be used where I have used "Die" here, which would appear to give a seemless transition. and perhaps without the need of editing the first new thread.

I have tried these as changes to an existing logbook on my system. and they appeared to work fine. but in my case as a single user, I could always change the Die number, a feature I guess you do not want.  I guess there is a way in the config file, but I'm running out of steam for today.  David.

This was given to me by Andreas L, 

In my elog.cfg file, I have the following:

Preset text = $shell(date '+[%d %b %y]')\n

and this puts at the top of every new thread I make today the following line

[09 Apr 24]

And for the same result for every reply as well, I have in elog.cfg

Prepend on reply = $shell(date '+[%d %b %y]')\n\n----------\n

with the ten dash characters to show the end of the thread, so the reply entry goes above the dashes.

Obviously time, name of day etc can be included by using the strftime 


> > This is a nice idea, but currently no text substations in templates are implemented. It only works in attributes right now.
> 
> but can it be done by javascript injection? load a custom .js or .html file, in this file run javascript code to root down the DOM tree until you 
> find the right place, replace .innerHTML with current date?
> 
> K.O.

This was given to me by Andreas Luedeke of this parish. 

In my elog.cfg file, I have the following:

Preset text = $shell(date '+[%d %b %y]')\n

and this puts at the top of every new thread I make today the following line

[09 Apr 24]

And for the same result for every reply as well, I have in elog.cfg

Prepend on reply = $shell(date '+[%d %b %y]')\n\n----------\n

with the ten dash characters to show the end of the thread, so the reply entry goes above the dashes.

Obviously time, name of day etc can be included by using the strftime codes.


> > This is a nice idea, but currently no text substations in templates are implemented. It only works in attributes right now.
> 
> but can it be done by javascript injection? load a custom .js or .html file, in this file run javascript code to root down the DOM tree until you 
> find the right place, replace .innerHTML with current date?
> 
> K.O.