- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Feature-creep will ensure that systemd stays
|
|
|
Comments (195)
Systemd is like a cancer metastzing all over Linux
155 earlier comments in the full thread.
Quoting:I have read the manual and found how to generate text files from the logs and how to do so on a remote host that is running., just curious if it can be done on a binary file mounted in a location that is not standard for systemd, without affecting your current running logs.
That's an excellent question. Because one would ordinarily boot a CDROM or USB drive and then mount the correct place for text logs. After that, cat, less, grep, and etcetera are sufficient. Heck, even pico could be used.
Be interesting to know how to deal with a similar situation if the logs are binary only.
> one would ordinarily boot a CDROM or USB drive and then mount the correct place for text logs. After that, cat, less, grep, and etcetera are sufficient. Heck, even pico could be used.
Exactly!
Exactly!
@number6x:
Here's the documentation for the raw binary log format.
http://www.freedesktop.org/wiki/Software/systemd/journal-files/
Here's the documentation on connecting to a remote journald.
http://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html
And you've already figured out how to generate text logs from the binary storage. So, I imagine you've figured out how to configure journald to write a text log in real time as well...
http://www.freedesktop.org/software/systemd/man/journald.conf.html
Here's the documentation for the raw binary log format.
http://www.freedesktop.org/wiki/Software/systemd/journal-files/
Here's the documentation on connecting to a remote journald.
http://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html
And you've already figured out how to generate text logs from the binary storage. So, I imagine you've figured out how to configure journald to write a text log in real time as well...
http://www.freedesktop.org/software/systemd/man/journald.conf.html
Quoting:ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=
Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is enabled but no syslog daemon is running, the respective option has no effect. By default, only forwarding wall is enabled. These settings may be overridden at boot time with the kernel command line options "systemd.journald.forward_to_syslog=", "systemd.journald.forward_to_kmsg=", "systemd.journald.forward_to_console=" and "systemd.journald.forward_to_wall=". When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below.
@me1010
Thanks that is what I was looking for.
Looks like if I get a binary only dead fedora machine I'll have to write a program to access the files. Reading in bson files, converting to json and extracting the text I need. Vastly more difficult than just reading a file. They should add a json version number as a parameter in the header parameters. Future versions of json may have incompatibilities( like trying to read a utf text file with an old text editor).
If the user has set up their system to write text logs from the binary journals then I could just read the text, but who knows their system is going to crash hard before it does?
It would be nice if systemd would use text journals by default. logs are write only so there is no benefit to binary. I can understand operating cached files that are being used read-write being binary, but even these can be persisted to disk in text format, if needed.
Its almost like seeing a program written by someone who is proud that their code is confusing and obfuscated.
Systemd is very young and still only deployed in experimental distros like fedora. Things like this should, hopefully, be whittled away over the next few years when systemd might start being used for real deployments.
Thanks again
Thanks that is what I was looking for.
Looks like if I get a binary only dead fedora machine I'll have to write a program to access the files. Reading in bson files, converting to json and extracting the text I need. Vastly more difficult than just reading a file. They should add a json version number as a parameter in the header parameters. Future versions of json may have incompatibilities( like trying to read a utf text file with an old text editor).
If the user has set up their system to write text logs from the binary journals then I could just read the text, but who knows their system is going to crash hard before it does?
It would be nice if systemd would use text journals by default. logs are write only so there is no benefit to binary. I can understand operating cached files that are being used read-write being binary, but even these can be persisted to disk in text format, if needed.
Its almost like seeing a program written by someone who is proud that their code is confusing and obfuscated.
Systemd is very young and still only deployed in experimental distros like fedora. Things like this should, hopefully, be whittled away over the next few years when systemd might start being used for real deployments.
Thanks again
I don't see an upside to the binary logs that is worth the downside. Fortunately, I believe you can set systemd to use text logs. Really, I think text logs should be the default, and the binary ones should only be used by people who specifically want them. That would make a lot more sense to me.
@CFWhitman
I agree totally. As I stated, logs are write only so there is no benefit to keeping them in bson.
As a counterexample, mongodb stores data in tables in bson format. The benefits include indexing and search as well as storage. Access for update in a working data store makes sense. Mongodb takes text based json in and will present text based json when queried. You can specify bson for output (ie if piping to a utility or api that expects it).
But system logs are really only needed when something goes wrong, they should be write and forget, append only. binary bson does not make sense in this use case. It may be cool and shiny in a 'look what I can do' kind of way, but it is not a good design.
If systemd is using logs in a read write kind of way, that is really borked. If systemd has a need for a read write temp storage, it should separate that functionality from the logs. Logs --> write only and read write stuff in a separate file in /var or /tmp or even cached in ram. That would be a like a spool, or cache file.
I agree totally. As I stated, logs are write only so there is no benefit to keeping them in bson.
As a counterexample, mongodb stores data in tables in bson format. The benefits include indexing and search as well as storage. Access for update in a working data store makes sense. Mongodb takes text based json in and will present text based json when queried. You can specify bson for output (ie if piping to a utility or api that expects it).
But system logs are really only needed when something goes wrong, they should be write and forget, append only. binary bson does not make sense in this use case. It may be cool and shiny in a 'look what I can do' kind of way, but it is not a good design.
If systemd is using logs in a read write kind of way, that is really borked. If systemd has a need for a read write temp storage, it should separate that functionality from the logs. Logs --> write only and read write stuff in a separate file in /var or /tmp or even cached in ram. That would be a like a spool, or cache file.
@CFWhitman:
Here's an oldie but goodie rather balanced view of journald and binary logging:
http://lwn.net/Articles/468381/
Here's an oldie but goodie rather balanced view of journald and binary logging:
http://lwn.net/Articles/468381/
Careful me1010, that is definitely an article you do not want to point to in support of systemd.
I would say that it pretty well captures the reasons why systemd is meeting resistance. Yes there are problems. The problems are due to cruft built up over time.
The solution to a house of cards system like that is not to offer a huge overarching control structure that will be bent and twisted to solve all the issues. That would be like hiring Accenture to code your solutions. It is going to end up as more of a nightmare. I think that article may be the straw that pushes me to the anti-sysemd side. It seems like lessons I had learned over the first 10 to 15 years in my career need to be learned by the systemd team.
The logs should not be used as inputs to the init system, or for two way communication of services. You really have no idea of the synchronization delays of software writing to logs. It just boggles my mind that a hack like that would even occur to someone. If the init system needs information it should send a message to the service or daemon running and query that information. Those messages are great candidates for binary journalled format. However writing systemd to scrounge the log files for messages is a duct tape and bailing wire solution. It is not just a bad design, but bad in a way that is mind boggling. I'm stupefied.
The more I learn The more I am amazed at this and begin to understand the extremely vocal opposition.
Bury that article and never mention it again if you are a supporter of systemd. It reads like something we would have hacked together in the early eighties.
The solution to a house of cards system like that is not to offer a huge overarching control structure that will be bent and twisted to solve all the issues. That would be like hiring Accenture to code your solutions. It is going to end up as more of a nightmare. I think that article may be the straw that pushes me to the anti-sysemd side. It seems like lessons I had learned over the first 10 to 15 years in my career need to be learned by the systemd team.
The logs should not be used as inputs to the init system, or for two way communication of services. You really have no idea of the synchronization delays of software writing to logs. It just boggles my mind that a hack like that would even occur to someone. If the init system needs information it should send a message to the service or daemon running and query that information. Those messages are great candidates for binary journalled format. However writing systemd to scrounge the log files for messages is a duct tape and bailing wire solution. It is not just a bad design, but bad in a way that is mind boggling. I'm stupefied.
The more I learn The more I am amazed at this and begin to understand the extremely vocal opposition.
Bury that article and never mention it again if you are a supporter of systemd. It reads like something we would have hacked together in the early eighties.
@number6x:
The article is a really good example of how to discuss the actual technical attributes, issues, and merits of systemd without resorting to posting threads entitled as this one is...
I certainly agree there are problems with systemd. But that in no way means it isn't a good forward looking start on something that has the potential to bring very useful innovation to the GNU/Linux world. And the fact that there are problems is definitely not cause to call those who wrote it and support it akin to an 'evil' group intent on destroying the Linux ecosystem.
So, yes... the article is a great one to refer to if you happen to be a systemd supporter.
The article is a really good example of how to discuss the actual technical attributes, issues, and merits of systemd without resorting to posting threads entitled as this one is...
I certainly agree there are problems with systemd. But that in no way means it isn't a good forward looking start on something that has the potential to bring very useful innovation to the GNU/Linux world. And the fact that there are problems is definitely not cause to call those who wrote it and support it akin to an 'evil' group intent on destroying the Linux ecosystem.
So, yes... the article is a great one to refer to if you happen to be a systemd supporter.
I also just noticed that the article is quite old and may not reflect actual systemd design as of today. I will take it with a grain of salt and try not to let it prejudice me too much.
I actually said it should not be referred to in support of systemd, it raises troubling issues with the basic design philosophy of systemd back in 2011.
I actually said it should not be referred to in support of systemd, it raises troubling issues with the basic design philosophy of systemd back in 2011.
@number6x:
quoting from the article I referenced:
quoting from the article I referenced:
Quoting: To restrict ourselves to what Unix did is an almost certain way to share Unix's fate. We can do better than that - indeed, we have done better than that - but, to do so, we need to create an environment where developers are willing to take some technical risks. Bad ideas need to be exposed as such whenever possible, but ideas should not be shot down just because they do not preserve the way our grandparents did things. The Journal may or may not turn into a sensible option, but the process that creates things like the Journal is one of the most important things we have.
@me1010,
The paragraph you quote is probably the best way to summarize the legitimate complaints about systemd. It is one of the strongest arguments against it. The headline for this article should be: "SystemD lead developer agrees with naysayers, declares SystemD not sensible."
Yes be bold and Plant a seed. See what grows.But when it comes time to harvest, can the systemd developers be bold and daring?
Are they willing to take the ripe fruit, and to also discard the rotten? So far they are not willing. They are doing just as 'their grandfathers' did. They are taking the bad with the good, because they wrote it and cannot bear to discard it or admit it is bad.
The bad ideas are being exposed and their response is to ignore the exposure.
Again, this is fine in Red Hat's playground distribution, Fedora, but it is, as the systemd developer's say them selves, not a sensible idea.
So when you see someone complain, that there are bad ideas in systemd and it does not make sense to do some of these things, then remember this quote.
The paragraph you quote is probably the best way to summarize the legitimate complaints about systemd. It is one of the strongest arguments against it. The headline for this article should be: "SystemD lead developer agrees with naysayers, declares SystemD not sensible."
Yes be bold and Plant a seed. See what grows.But when it comes time to harvest, can the systemd developers be bold and daring?
Are they willing to take the ripe fruit, and to also discard the rotten? So far they are not willing. They are doing just as 'their grandfathers' did. They are taking the bad with the good, because they wrote it and cannot bear to discard it or admit it is bad.
The bad ideas are being exposed and their response is to ignore the exposure.
Again, this is fine in Red Hat's playground distribution, Fedora, but it is, as the systemd developer's say them selves, not a sensible idea.
So when you see someone complain, that there are bad ideas in systemd and it does not make sense to do some of these things, then remember this quote.
@number6x:
I take the precise opposite interpretation. So, we'll just have to agree to disagree on the meaning, although the comments after the article are mixed with no one, at all, claiming any massive overarching insurmountable obstacle to systemd adoption.
I take the precise opposite interpretation. So, we'll just have to agree to disagree on the meaning, although the comments after the article are mixed with no one, at all, claiming any massive overarching insurmountable obstacle to systemd adoption.
@me1010,
I think you are beginning to see why there is so much opposition to systemd. The proponents keep listing the benefits they see in systemd, and the opponents keep listing the drawbacks. As I posted earlier in this thread:
So what proponents keep thinking will convince others to back systemd is actually causing others to reject and oppose systemd. The more proponents continue to trumpet what they perceive as benefits, the more people are convinced systemd is a fundamentally flawed solution to a problem that was not too big a deal.
I started as someone who was interested in learning how things I do will have to be changed as systemd is adopted. The more I learned, and thanks to the information you have pointed out, I now agree that systemd is fundamentally flawed and should not be adopted without major re-writes.
It is almost as if someone determined that there was a problem with baby ducklings getting struck by cars when crossing the road in central Florida, and the systemd team has stated that they have a solution, their solution will make sure that the hungry moose in the Yukon territory will be well fed this year. When people complain about the solution not meeting the needs, the systemd team accuses the complainers of not caring about the moose! They need to examine what they have built and fix the problems, but they refuse to accept that their design has any problems.
Shiny and new is not usually a good thing. There are good reasons why the most popular programming languages throughout history are old and ugly. Things like COBOL, C and C++.
I think you are beginning to see why there is so much opposition to systemd. The proponents keep listing the benefits they see in systemd, and the opponents keep listing the drawbacks. As I posted earlier in this thread:
Quoting:The proponents claim the benefits of systemd are:
It's new and the current init solution is outdated
It has many new features
It replaces old static text based logs and configurations with binary versions
It runs as a binary with pluggable modules
It integrates well with Red Hat's virtualization technology
It boots really fast
And the opponents of systemd claim:
It's too new and not as stable as the current mature init solution
It has many new features (leading to complexity and increasing the chance of more problems (KISS principle))
It replaces old static text based logs and configurations with binary versions (which adds complexity without real benefit)
It runs as a binary with pluggable modules (instead of reducing complexity and dependencies)
SysV init works just fine with Red Hat's virtualization technology, not everything needs to be integrated.
I boot once a decade and want it to work and not crash during boot
So what proponents keep thinking will convince others to back systemd is actually causing others to reject and oppose systemd. The more proponents continue to trumpet what they perceive as benefits, the more people are convinced systemd is a fundamentally flawed solution to a problem that was not too big a deal.
I started as someone who was interested in learning how things I do will have to be changed as systemd is adopted. The more I learned, and thanks to the information you have pointed out, I now agree that systemd is fundamentally flawed and should not be adopted without major re-writes.
It is almost as if someone determined that there was a problem with baby ducklings getting struck by cars when crossing the road in central Florida, and the systemd team has stated that they have a solution, their solution will make sure that the hungry moose in the Yukon territory will be well fed this year. When people complain about the solution not meeting the needs, the systemd team accuses the complainers of not caring about the moose! They need to examine what they have built and fix the problems, but they refuse to accept that their design has any problems.
Shiny and new is not usually a good thing. There are good reasons why the most popular programming languages throughout history are old and ugly. Things like COBOL, C and C++.
Nooooo ! Not COBOL! Think of the child-processes! Oh, the huge manatee!
This should still be valid, but it has been many years...
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE.
AUTHOR. NUMBER6X
********************************
** A sample cobol program **
********************************
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INPUT-FILE ASSIGN TO SYSIN
ORGANIZATION IS LINE SEQUENTIAL.
SELECT PRINT-FILE ASSIGN TO SYSOUT
ORGANIZATION IS LINE SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD INPUT-FILE
RECORD CONTAINS 43 CHARACTERS
DATA RECORD IS DATA-IN.
01 DATA-IN PIC X(43).
FD PRINT-FILE
RECORD CONTAINS 80 CHARACTERS
DATA RECORD IS PRINT-LINE.
01 PRINT-LINE PIC X(80).
WORKING-STORAGE SECTION.
01 ROWS-REMAIN-FLAG PIC X(2) VALUE SPACES.
01 RECORDS-WRITTEN PIC 9(2).
01 DETAIL-LINE.
05 FILLER PIC X(7) VALUE SPACES.
05 INPUT-IMAGE PIC X(43).
05 FILLER PIC X(30) VALUE SPACES.
01 SUMMARY-LINE.
05 FILLER PIC X(7) VALUE SPACES.
05 TOTAL-READ PIC 9(2).
05 FILLER PIC X VALUE SPACE.
05 FILLER PIC X(17)
VALUE 'Records were read'.
05 FILLER PIC X(53) VALUE SPACES.
PROCEDURE DIVISION.
000-RUN-PROGRAM.
PERFORM 100-STARTUP.
PERFORM 300-PROCESS-RECORDS
UNTIL ROWS-REMAIN-FLAG = 'NO'.
PERFORM 500-PRINT-SUMMARY.
PERFORM 900-FINISH.
STOP RUN.
100-STARTUP.
OPEN INPUT INPUT-FILE
OUTPUT PRINT-FILE.
MOVE ZERO TO RECORDS-WRITTEN.
PERFORM 800-READ-INPUT.
300-PROCESS-RECORDS.
INITIALIZE PRINT-LINE.
MOVE DATA-IN TO INPUT-IMAGE.
MOVE DETAIL-LINE TO PRINT-LINE.
WRITE PRINT-LINE.
ADD 1 TO RECORDS-WRITTEN.
PERFORM 800-READ-INPUT.
500-PRINT-SUMMARY.
INITIALIZE PRINT-LINE.
MOVE RECORDS-WRITTEN TO TOTAL-READ.
MOVE SUMMARY-LINE TO PRINT-LINE.
WRITE PRINT-LINE.
800-READ-INPUT.
READ INPUT-FILE
AT END MOVE 'NO' TO ROWS-REMAIN-FLAG
END-READ.
900-FINISH.
CLOSE INPUT-FILE
PRINT-FILE.
@ number6x:
Let me guess,... that same program can be written in about 3 lines of python?!?!
Let me guess,... that same program can be written in about 3 lines of python?!?!
And one line of Bash.
Yes, but about 10 -12 lines of python would be very clear and expandable. I write programs like this in python everyday.
It could be much smaller in COBOL. This is a good shell to start from. It is easily expanded and functionality is compartmentalized in logical sections.
It follows the same format as suggested for basic data crunching in books like: Data Crunching: Solve Everyday Problems using Java, Python, and More:
Open files an take care of start up tasks.
Read first file into input.
Loop to process file line by line, doing what needs to be done. read the next record and the end of each processing loop. break out of processing loop at end of file.
take care of finalization tasks and close files.
end.
(Sadly that book is out of print.)
A similar program format in python would be:
Very expandable and useful pattern for processing sequential data input.
It could be much smaller in COBOL. This is a good shell to start from. It is easily expanded and functionality is compartmentalized in logical sections.
It follows the same format as suggested for basic data crunching in books like: Data Crunching: Solve Everyday Problems using Java, Python, and More:
Open files an take care of start up tasks.
Read first file into input.
Loop to process file line by line, doing what needs to be done. read the next record and the end of each processing loop. break out of processing loop at end of file.
take care of finalization tasks and close files.
end.
(Sadly that book is out of print.)
A similar program format in python would be:
import sys
# Read input = open(sys.argv[1], "r") lines = input.readlines() input.close()
# Process lines.reverse()
# Write output = open(sys.argv[2], "w") for line in lines: print >> output, line.strip() output.close()
Very expandable and useful pattern for processing sequential data input.
Too bad the name Kudzu is already used by Red Hat...
Maybe they could rename it "Audrey Junior"?
Or "poison ivy"?
With the added hilarity that both Kudzu and Systemd (in part) is about hardware hotplugging...
They need to rename it to "SystemBorg"
Systemd: A Wager and a civility pledge.
Probably not the most appropriate location for this - but...
In the interest of 'putting up and shutting up' regarding systemd...
I'll wager $5.00 USD in donations to the GNU Octave project per taker up to a value of $150.00 that in five years systemd is still the default init of most GNU/Linux distros.
Myself and all those taking the wager pledge not to comment on systemd in any on-line forum, story, post, media, website, newspaper, etc. for the next 90 days after commitment to wager.
****
I commit now - next allowable systemd comment no earlier than Jan 22nd 2015. *me1010
In the interest of 'putting up and shutting up' regarding systemd...
I'll wager $5.00 USD in donations to the GNU Octave project per taker up to a value of $150.00 that in five years systemd is still the default init of most GNU/Linux distros.
Myself and all those taking the wager pledge not to comment on systemd in any on-line forum, story, post, media, website, newspaper, etc. for the next 90 days after commitment to wager.
****
I commit now - next allowable systemd comment no earlier than Jan 22nd 2015. *me1010
I salute you, sir.
As promised:
Donation to GNU Octave.
Donation to GNU Octave.
Don't understand your wager nor what you are trying to prove.
> in five years systemd is still the default init of most GNU/Linux distros
None of use disputes that, with the grip that Red Hat has these days over the Linux ecosystem that's unfortunately very likely, but it's a bad thing, not a good thing, and that's what you don't seem to understand.
None of use disputes that, with the grip that Red Hat has these days over the Linux ecosystem that's unfortunately very likely, but it's a bad thing, not a good thing, and that's what you don't seem to understand.
In five years Britney Spears and Justin Bieber will still be more popular than Wayne Shorter and Charles Mingus.
Quoting: In five years Britney Spears and Justin Bieber will still be more popular than Wayne Shorter and Charles Mingus.
And we have the first Godwin's!
How does equating pop stars with jazz musicians qualify as invoking Godwin's Law???
@JaseP
Of course, kikinovak was not equating Spears/Bieber with Shorter/Mingus, but was merely suggesting the similarity in the prevalence of shallow Spears/Bieber to that of systemd, in contrast to the relative obscurity of venerable jazz legends Shorter/Mingus (and future non-systemd distros).
Of course, kikinovak was not equating Spears/Bieber with Shorter/Mingus, but was merely suggesting the similarity in the prevalence of shallow Spears/Bieber to that of systemd, in contrast to the relative obscurity of venerable jazz legends Shorter/Mingus (and future non-systemd distros).
Invoking Britney Spears and Justin Bieber is darn near terroristic.
I was accused of violating Godwin's law (or invoking it, same thing I guess) by mentioning Prussia.
For the record: I'm not particularly anti- or pro-systemd. I use Slackware, which is one of the rare remaining distributions that hasn't implemented it yet. The day Slackware moves to systemd, I'll just do a bit of RTFM and use it. What motivated me was the equation "popularity = quality". History has taught us that more often than not, a weaker technology will prevail for obscure reasons. Remember Video 2000 vs. Betamax vs. VHS? Of the three candidates, Video 2000 was by far the best from a technical point of view, but VHS (the worst) eventually won the race.
Quoting:History has taught us that more often than not, a weaker technology will prevail for obscure reasons.
Same is true of HD-DVD vs. BluRay. HD-DVD had better backward compatibility with the DVD standard (in terms of using it on computers), and better compatibility with the DVD-RW technology. BluRay won out, primarily, because the popular Playstation 3 had BluRay built in, usable without any additional purchases/upgrading of a Playstation 3 unit and was about the same cost as stand-alone BluRay or HD-DVD players (with the added benefit of being a popular gaming system, backwardly compatible with the Playstation 2). Similarly, your (kikinovak) cited Video 2000 vs. Betamax Vs. VHS was a case of the worst tech making it as the standard, for economic reasons (VHS units were cheaper to produce for those wanting to make competing units,... no/low royalties to pay).
But, Microsoft Windows is the most popular OS, so it must be the best!
What is considered the 'Best' product to the market, is not usually what a human being would consider 'Best'. The selection criteria re very different. The market usually chooses a product that is adequate and cheap.
What is considered the 'Best' product to the market, is not usually what a human being would consider 'Best'. The selection criteria re very different. The market usually chooses a product that is adequate and cheap.
Yes BluRay won principally because of the PS3.
I can't speak to Video 2000, but the whole Betamax was superior just isn't correct. It may have had marginally higher video quality (debatable), but that is not what users valued. What they valued was the ability to record an entire movie unattended (or more). I remember using VHS for 20 years, and I don't think I ever recorded anything using SP mode, because getting six hours to a tape was more important than an increase in visual quality that was not noticeable on my TV.
http://www.theguardian.com/technology/2003/jan/25/comment.co...
http://www.theguardian.com/technology/2003/jan/25/comment.co...
Quoting:I don't think I ever recorded anything using SP mode, because getting six hours to a tape was more important than an increase in visual quality that was not noticeable on my TV.
I'm STILL using VHS. I have two recorders, and I never use SP because it takes FOREVER to rewind and to FF through commercials. EP forever!!!! (or until both VCRs break).
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
It may be as simple as running a config utility to point a running instance to a binary log on a different mount point and using the command to generate a text based log.
For sysvinit I'll just mount the drives and read the logs. This is almost always a first step when I get a crashed machine.
I have scripts to dump the last day of many text based log files and some cats and greps to look for certain things...
As I said it may be as simple as running a config to add to the path where the binary file is, generate a text file and run my scripts.
Or it may not. I just don't know.
I have read the manual and found how to generate text files from the logs and how to do so on a remote host that is running., just curious if it can be done on a binary file mounted in a location that is not standard for systemd, without affecting your current running logs.