Don't care on the politics or development trends and history

Edited by crazy June 15, 2022, 03:51:51 PM EDT

Do you want to fix it?

I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.

Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.

Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.

That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.

Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.

There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.

Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.

Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.

Edited by crazy June 15, 2022, 03:52:52 PM EDT

Don't care on the politics or development trends and history

Do you want to fix it?

I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.

Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.

If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.

Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.

That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.

Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.

There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.

Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.

Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.

Edited by crazy June 15, 2022, 04:13:27 PM EDT

Don't care on the politics or development trends and history

Do you want to fix it?

I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.

You want to follow forks because the main process can spawn children process before it gets to the point of actually reading your file. So you want to watch everything until you figure out that you don't need to follow forks because you're just getting too much damn information.

Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.

If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.

Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.

That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.

Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.

There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.

Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.

Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.

Edited by crazy June 15, 2022, 04:23:18 PM EDT

Don't care on the politics or development trends and history

Do you want to fix it?

I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.

You want to follow forks because the main process can spawn children process before it gets to the point of actually reading your file. So you want to watch everything until you figure out that you don't need to follow forks because you're just getting too much damn information.

Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.

If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.

Everything I described above can be accomplished in about three scripts with two or three lines apiece. A couple of pipes assigned into a variable. I'd probably put them in 10 line Perl scripts so I would have added instrumentation and logging for the script itself. But you're not going to be doing this.

Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.

That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.

Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.

There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.

Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.

Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.

Edited by crazy June 15, 2022, 04:26:37 PM EDT

Don't care on the politics or development trends and history

Do you want to fix it?

I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.

You want to follow forks because the main process can spawn children process before it gets to the point of actually reading your file. So you want to watch everything until you figure out that you don't need to follow forks because you're just getting too much damn information.

Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.

If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.

Everything I described above can be accomplished in about three scripts with two or three lines apiece. A couple of pipes assigned into a variable. I'd probably put them in 10 line Perl scripts so I would have added instrumentation and logging for the script itself. But you're not going to be doing this.

Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.

That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.

Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.

There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.

Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.

Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.

I've used the words redirect and pipes. If you do not know how to use multiple '|' and then finally '>' and '2>&1' and backticks and variable assignment in a script then maybe you are part of the desktop Linux generation that should go back to something else.

But if you do understand these things then you can do pretty much anything on a Linux system.

I've given up believing Linux systems will ever be general purpose desktops. But for experts willing to learn, they're amazing.

Edited by crazy June 15, 2022, 04:32:48 PM EDT

Don't care on the politics or development trends and history

Do you want to fix it?

I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.

You want to follow forks because the main process can spawn children process before it gets to the point of actually reading your file. So you want to watch everything until you figure out that you don't need to follow forks because you're just getting too much damn information.

Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.

If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.

Everything I described above can be accomplished in about three scripts with two or three lines apiece. A couple of pipes assigned into a variable. I'd probably put them in 10 line Perl scripts so I would have added instrumentation and logging for the script itself. But you're not going to be doing this.

Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.

That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.

Using this method, you can see when a vendor is attempting to open up a series of cascading files and failing to handle errors. They just didn't bother checking the code that was returned.

Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.

There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.

Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.

Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.

I've used the words redirect and pipes. If you do not know how to use multiple '|' and then finally '>' and '2>&1' and backticks and variable assignment in a script then maybe you are part of the desktop Linux generation that should go back to something else.

But if you do understand these things then you can do pretty much anything on a Linux system.

I've given up believing Linux systems will ever be general purpose desktops. But for experts willing to learn, they're amazing.

Welcome to IWETHEY!