Gary, computers are hard and shouldn't be used by retired folks. :) Run it like below, it will load last. Use AI for docs - much easier and faster than our brains.
Type=idle
Behavior of idle is very similar to simple; however, actual execution of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving the output of shell services with the status output on the console. Note that this type is useful only to improve console output, it is not useful as a general unit ordering tool, and the effect of this service type is subject to a 5s timeout, after which the service program is invoked anyway.
https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html
Kevin
The following message was in the queue as being from a non-subscriber. I rarely check these things....
Brian
On Thu, Mar 13, 2025 at 03:50:43PM -0700, Kevin Brisson wrote:
Gary, computers are hard and shouldn't be used by retired folks. :) Run it like below, it will load last. Use AI for docs - much easier and faster than our brains. Type=idle
Behavior of idle is very similar to simple; however, actual execution of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving the output of shell services with the status output on the console. Note that this type is useful only to improve console output, it is not useful as a general unit ordering tool, and the effect of this service type is subject to a 5s timeout, after which the service program is invoked anyway. [1]https://www.freedesktop.org/software/systemd/man/latest/systemd.serv ice.html Kevin
References
I believe this was already posted to the list back in March, which is when it is dated. I haven't saved my emails since back then and would have to check the archive to get the context. But, I believe I was complaining about the overarching and unnecesarily complex nature of systemd :)
As an aside, as a result of that converstaion, I've looked in to Suspend on the desktop instead of going through the shutdown and reboot cycle. I haven't done it yet, but unless you are rebooting to "clean things up", it seems like a better way to do things and eliminates the need for developing boot scripts to re-establish the desired system configuration.
And yes, no one is perfect and neither am I :)
On Fri, Aug 08, 2025 at 01:27:35PM -0700, Brian E. Lavender wrote:
The following message was in the queue as being from a non-subscriber. I rarely check these things....
Brian
On Thu, Mar 13, 2025 at 03:50:43PM -0700, Kevin Brisson wrote:
Gary, computers are hard and shouldn't be used by retired folks. :) Run it like below, it will load last. Use AI for docs - much easier and faster than our brains. Type=idle
Behavior of idle is very similar to simple; however, actual execution of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving the output of shell services with the status output on the console. Note that this type is useful only to improve console output, it is not useful as a general unit ordering tool, and the effect of this service type is subject to a 5s timeout, after which the service program is invoked anyway. [1]https://www.freedesktop.org/software/systemd/man/latest/systemd.serv ice.html Kevin
References
-- Brian Lavender https://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Professor C. A. R. Hoare The 1980 Turing award lecture _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
I've been giving some thought to playing with systemd and making it actually useful. I should spend more time with the docs. :)
On Thu, Mar 13, 2025 at 03:50:43PM -0700, Kevin Brisson wrote:
Gary, computers are hard and shouldn't be used by retired folks. :) Run it like below, it will load last. Use AI for docs - much easier and faster than our brains.
Type=idle
Behavior of idle is very similar to simple; however, actual execution of the service program is delayed until all active jobs are dispatched. This may be used to avoid interleaving the output of shell services with the status output on the console. Note that this type is useful only to improve console output, it is not useful as a general unit ordering tool, and the effect of this service type is subject to a 5s timeout, after which the service program is invoked anyway.
https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html
Kevin
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
On Fri, Nov 07, 2025 at 12:37:31PM -0800, Gary wrote:
I've been giving some thought to playing with systemd and making it actually useful. I should spend more time with the docs. :)
Install Fedora 43 from a clean install and systemd should work fine. Is Slackware still on non systemd?
Brian
Fine is in the eye of the beholder. I've written some units and they end up not working the way I expect. Like killing and restarting the job until is hits the restart limit. Things may be "fine" now. I just need to understand why this is happening.
On Fri, Nov 07, 2025 at 12:45:57PM -0800, Brian E. Lavender wrote:
On Fri, Nov 07, 2025 at 12:37:31PM -0800, Gary wrote:
I've been giving some thought to playing with systemd and making it actually useful. I should spend more time with the docs. :)
Install Fedora 43 from a clean install and systemd should work fine. Is Slackware still on non systemd?
Brian
-- Brian Lavender https://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies."
Professor C. A. R. Hoare The 1980 Turing award lecture _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
On 11/7/25 12:45, Brian E. Lavender wrote:
Install Fedora 43 from a clean install and systemd should work fine. Is Slackware still on non systemd?
Brian
Slackware is still running on sysvinit. Years of experience with Slackware, Fedora, Ubuntu, CentOS, Red Hat, FreeBSD, ... haven't has a problem with sysvinit, have spent dozens of hours "supporting" systemd. I haven't experienced any tangible benefit, but from previous posts, and private conversations on this topic, you do. Could it be because you're a laptop user? I believe that laptops would be ideal for me, except that the keyboards are always a non-starter. I haven't ever tried a laptop keyboard that didn't make my fingers feel retarded.
I've felt that sisvinit is really all you need for a laptop or desktop, or possibly even a stand alone server.
But, after looking around, I took the path of least resistance and began using distros that use systemd.
Systemd has a lot of issues. It's monolithic. They went and built something that is very flexible, and then used it a way that hardly utilizes it. It is way more than someone with a laptop, desktop, or server really needs. It solves a problem that is really only a problem for someone who has lots of systems to maintain each of which may have different configurations. Unfortunately, they didn't make this as easy as it should be; see not using flexibility previouly mentioned.
It does get around some of the awkwardness of rc.local, for example. If only I could get it to work. That was an issue with rc.local too,as I recall.
I'm thinking that if I get some time, I'll play around with it.
On Sat, Nov 08, 2025 at 07:09:03AM -0800, Charles Polisher wrote:
On 11/7/25 12:45, Brian E. Lavender wrote:
Install Fedora 43 from a clean install and systemd should work fine. Is Slackware still on non systemd?
Brian
Slackware is still running on sysvinit. Years of experience with Slackware, Fedora, Ubuntu, CentOS, Red Hat, FreeBSD, ... haven't has a problem with sysvinit, have spent dozens of hours "supporting" systemd. I haven't experienced any tangible benefit, but from previous posts, and private conversations on this topic, you do. Could it be because you're a laptop user? I believe that laptops would be ideal for me, except that the keyboards are always a non-starter. I haven't ever tried a laptop keyboard that didn't make my fingers feel retarded.
-- Chuck Polisher _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
So, I've put some more time into this. After learning a lot, I got my ssh -g -R port to connect using the systemd user unit. But, when I try to use the port, the connection is made, but hangs before the password prompt. I see lots of examples that look just like what I am doing that apparently work fine LOL.
I was just at the system I want to connect to, after my most recent changes, and ssh to my remote system and could connect back using -p xxx localhost. So the tunnel worked, at least once.
Now, I'm at the remote system. I try ssh -pxxx localhost, and it just hangs after the client sends the banner. I think this is same as before.
So, when I run my ExecStart command from the command line, it works. But when running it inside a systemd unit, I have this issue.
It can't be firewall. It can't be network or DNS vs. straight IP. It can't be almost anything except systemd. But there is nothing in the logs.
I'm thinking the next step is wiresharking everything. But that sounds painful.
Having written cron jobs in the past, I'm sort of used to this kind of mystery. Same with rc.local stuff, sort of. So it isn't the ultimate condemnation. But, like, it should work LOL.
Any thoughts?
On Tue, Nov 11, 2025 at 10:58:40PM -0800, Gary wrote:
I've felt that sisvinit is really all you need for a laptop or desktop, or possibly even a stand alone server.
But, after looking around, I took the path of least resistance and began using distros that use systemd.
Systemd has a lot of issues. It's monolithic. They went and built something that is very flexible, and then used it a way that hardly utilizes it. It is way more than someone with a laptop, desktop, or server really needs. It solves a problem that is really only a problem for someone who has lots of systems to maintain each of which may have different configurations. Unfortunately, they didn't make this as easy as it should be; see not using flexibility previouly mentioned.
It does get around some of the awkwardness of rc.local, for example. If only I could get it to work. That was an issue with rc.local too,as I recall.
I'm thinking that if I get some time, I'll play around with it.
On Sat, Nov 08, 2025 at 07:09:03AM -0800, Charles Polisher wrote:
On 11/7/25 12:45, Brian E. Lavender wrote:
Install Fedora 43 from a clean install and systemd should work fine. Is Slackware still on non systemd?
Brian
Slackware is still running on sysvinit. Years of experience with Slackware, Fedora, Ubuntu, CentOS, Red Hat, FreeBSD, ... haven't has a problem with sysvinit, have spent dozens of hours "supporting" systemd. I haven't experienced any tangible benefit, but from previous posts, and private conversations on this topic, you do. Could it be because you're a laptop user? I believe that laptops would be ideal for me, except that the keyboards are always a non-starter. I haven't ever tried a laptop keyboard that didn't make my fingers feel retarded.
-- Chuck Polisher _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
It's always permissions. B-)
On Tue, Nov 25, 2025 at 3:27 PM Gary saclug@garymcglinn.com wrote:
So, I've put some more time into this. After learning a lot, I got my ssh -g -R port to connect using the systemd user unit. But, when I try to use the port, the connection is made, but hangs before the password prompt. I see lots of examples that look just like what I am doing that apparently work fine LOL.
I was just at the system I want to connect to, after my most recent changes, and ssh to my remote system and could connect back using -p xxx localhost. So the tunnel worked, at least once.
Now, I'm at the remote system. I try ssh -pxxx localhost, and it just hangs after the client sends the banner. I think this is same as before.
So, when I run my ExecStart command from the command line, it works. But when running it inside a systemd unit, I have this issue.
It can't be firewall. It can't be network or DNS vs. straight IP. It can't be almost anything except systemd. But there is nothing in the logs.
I'm thinking the next step is wiresharking everything. But that sounds painful.
Having written cron jobs in the past, I'm sort of used to this kind of mystery. Same with rc.local stuff, sort of. So it isn't the ultimate condemnation. But, like, it should work LOL.
Any thoughts?
On Tue, Nov 11, 2025 at 10:58:40PM -0800, Gary wrote:
I've felt that sisvinit is really all you need for a laptop or desktop,
or possibly even a stand alone server.
But, after looking around, I took the path of least resistance and began
using distros that use systemd.
Systemd has a lot of issues. It's monolithic. They went and built
something that is very flexible, and then used it a way that hardly utilizes it. It is way more than someone with a laptop, desktop, or server really needs. It solves a problem that is really only a problem for someone who has lots of systems to maintain each of which may have different configurations. Unfortunately, they didn't make this as easy as it should be; see not using flexibility previouly mentioned.
It does get around some of the awkwardness of rc.local, for example. If
only I could get it to work. That was an issue with rc.local too,as I recall.
I'm thinking that if I get some time, I'll play around with it.
On Sat, Nov 08, 2025 at 07:09:03AM -0800, Charles Polisher wrote:
On 11/7/25 12:45, Brian E. Lavender wrote:
Install Fedora 43 from a clean install and systemd should work fine.
Is
Slackware still on non systemd?
Brian
Slackware is still running on sysvinit. Years of experience with Slackware, Fedora, Ubuntu, CentOS, Red Hat, FreeBSD, ... haven't has a problem with sysvinit, have spent dozens of hours "supporting" systemd. I haven't experienced any tangible benefit, but from previous posts, and private conversations on this topic, you do. Could it be because you're a laptop user? I believe that laptops would be ideal for me, except that the keyboards are always a non-starter. I haven't ever tried a laptop keyboard that didn't make my fingers feel retarded.
-- Chuck Polisher _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Perhaps, but it seems to work intermittently and unpredictably. I looked for contention on the port, but couldn't find any.
....So, I rebooted the client and restarted the systemd unit/service on the server and everything works. Interestingly systemctl status for the unit showed that everything was OK before the restart, but nothing worked.
During the course of all this I learned, what is perhaps obvious, that SSH does a lot of things at the terminal config level. If something in SSH terminates at an unexpected point, things can be messed up. Reset should fix this, but apparently not.
That's my story and I'm sticking to it LOL.
On Tue, Nov 25, 2025 at 06:23:03PM -0700, Linus Sphinx wrote:
It's always permissions. B-)
On Tue, Nov 25, 2025 at 3:27 PM Gary saclug@garymcglinn.com wrote:
So, I've put some more time into this. After learning a lot, I got my ssh -g -R port to connect using the systemd user unit. But, when I try to use the port, the connection is made, but hangs before the password prompt. I see lots of examples that look just like what I am doing that apparently work fine LOL.
I was just at the system I want to connect to, after my most recent changes, and ssh to my remote system and could connect back using -p xxx localhost. So the tunnel worked, at least once.
Now, I'm at the remote system. I try ssh -pxxx localhost, and it just hangs after the client sends the banner. I think this is same as before.
So, when I run my ExecStart command from the command line, it works. But when running it inside a systemd unit, I have this issue.
It can't be firewall. It can't be network or DNS vs. straight IP. It can't be almost anything except systemd. But there is nothing in the logs.
I'm thinking the next step is wiresharking everything. But that sounds painful.
Having written cron jobs in the past, I'm sort of used to this kind of mystery. Same with rc.local stuff, sort of. So it isn't the ultimate condemnation. But, like, it should work LOL.
Any thoughts?
On Tue, Nov 11, 2025 at 10:58:40PM -0800, Gary wrote:
I've felt that sisvinit is really all you need for a laptop or desktop,
or possibly even a stand alone server.
But, after looking around, I took the path of least resistance and began
using distros that use systemd.
Systemd has a lot of issues. It's monolithic. They went and built
something that is very flexible, and then used it a way that hardly utilizes it. It is way more than someone with a laptop, desktop, or server really needs. It solves a problem that is really only a problem for someone who has lots of systems to maintain each of which may have different configurations. Unfortunately, they didn't make this as easy as it should be; see not using flexibility previouly mentioned.
It does get around some of the awkwardness of rc.local, for example. If
only I could get it to work. That was an issue with rc.local too,as I recall.
I'm thinking that if I get some time, I'll play around with it.
On Sat, Nov 08, 2025 at 07:09:03AM -0800, Charles Polisher wrote:
On 11/7/25 12:45, Brian E. Lavender wrote:
Install Fedora 43 from a clean install and systemd should work fine.
Is
Slackware still on non systemd?
Brian
Slackware is still running on sysvinit. Years of experience with Slackware, Fedora, Ubuntu, CentOS, Red Hat, FreeBSD, ... haven't has a problem with sysvinit, have spent dozens of hours "supporting" systemd. I haven't experienced any tangible benefit, but from previous posts, and private conversations on this topic, you do. Could it be because you're a laptop user? I believe that laptops would be ideal for me, except that the keyboards are always a non-starter. I haven't ever tried a laptop keyboard that didn't make my fingers feel retarded.
-- Chuck Polisher _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
I started down this path because I won't always be able to physically access the server and I don't want the -R port to stop working, as it is the only way I can access the system to do anything, as it is behind a firewall.
If I just ran the ssh port forward in the background, I could get the famouns "pipe broken" error. I was hoping systemd would restart if this happened. I don't think it will, but I'll have to wait and see.
I have the Restart=on-failure. With Restart=always, it wouldn't run and seemed to be restarting a lot. But, I didn't see any restart limit errors in the logs, so I'm not exactly sure what was up.
Perhaps I'll look into the watchdog feature. I don't think this will get me anything though, since systemctl status thinks everything is fine and I have no reason to believe it wouldn't keep sending the necessary signal.
I'm thinking I'll have to implement my own watchdog feature, which is what I was hoping to avoid.
I had a lot of issues. I attributed these to systemd. Really, I think it was ssh. But it does seem that systemd is complex and might be a bit fragile. Lots of logging was generated but not visible. Gemini/Google suggest that these kind of "terminal configuration" issues can cause that problem. When things get fixed, the log entries are there, but it's not optimal.
On Tue, Nov 25, 2025 at 08:37:52PM -0800, Gary wrote:
Perhaps, but it seems to work intermittently and unpredictably. I looked for contention on the port, but couldn't find any.
....So, I rebooted the client and restarted the systemd unit/service on the server and everything works. Interestingly systemctl status for the unit showed that everything was OK before the restart, but nothing worked.
During the course of all this I learned, what is perhaps obvious, that SSH does a lot of things at the terminal config level. If something in SSH terminates at an unexpected point, things can be messed up. Reset should fix this, but apparently not.
That's my story and I'm sticking to it LOL.
On Tue, Nov 25, 2025 at 06:23:03PM -0700, Linus Sphinx wrote:
It's always permissions. B-)
On Tue, Nov 25, 2025 at 3:27 PM Gary saclug@garymcglinn.com wrote:
So, I've put some more time into this. After learning a lot, I got my ssh -g -R port to connect using the systemd user unit. But, when I try to use the port, the connection is made, but hangs before the password prompt. I see lots of examples that look just like what I am doing that apparently work fine LOL.
I was just at the system I want to connect to, after my most recent changes, and ssh to my remote system and could connect back using -p xxx localhost. So the tunnel worked, at least once.
Now, I'm at the remote system. I try ssh -pxxx localhost, and it just hangs after the client sends the banner. I think this is same as before.
So, when I run my ExecStart command from the command line, it works. But when running it inside a systemd unit, I have this issue.
It can't be firewall. It can't be network or DNS vs. straight IP. It can't be almost anything except systemd. But there is nothing in the logs.
I'm thinking the next step is wiresharking everything. But that sounds painful.
Having written cron jobs in the past, I'm sort of used to this kind of mystery. Same with rc.local stuff, sort of. So it isn't the ultimate condemnation. But, like, it should work LOL.
Any thoughts?
On Tue, Nov 11, 2025 at 10:58:40PM -0800, Gary wrote:
I've felt that sisvinit is really all you need for a laptop or desktop,
or possibly even a stand alone server.
But, after looking around, I took the path of least resistance and began
using distros that use systemd.
Systemd has a lot of issues. It's monolithic. They went and built
something that is very flexible, and then used it a way that hardly utilizes it. It is way more than someone with a laptop, desktop, or server really needs. It solves a problem that is really only a problem for someone who has lots of systems to maintain each of which may have different configurations. Unfortunately, they didn't make this as easy as it should be; see not using flexibility previouly mentioned.
It does get around some of the awkwardness of rc.local, for example. If
only I could get it to work. That was an issue with rc.local too,as I recall.
I'm thinking that if I get some time, I'll play around with it.
On Sat, Nov 08, 2025 at 07:09:03AM -0800, Charles Polisher wrote:
On 11/7/25 12:45, Brian E. Lavender wrote:
Install Fedora 43 from a clean install and systemd should work fine.
Is
Slackware still on non systemd?
Brian
Slackware is still running on sysvinit. Years of experience with Slackware, Fedora, Ubuntu, CentOS, Red Hat, FreeBSD, ... haven't has a problem with sysvinit, have spent dozens of hours "supporting" systemd. I haven't experienced any tangible benefit, but from previous posts, and private conversations on this topic, you do. Could it be because you're a laptop user? I believe that laptops would be ideal for me, except that the keyboards are always a non-starter. I haven't ever tried a laptop keyboard that didn't make my fingers feel retarded.
-- Chuck Polisher _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
I use Ubuntu on my servers and have never had a systemd / ssh issue. Getting Tomcat to work with systemd can be tricky especially if your startup sh script gets complex. I’m going to guess you probably have a permissions issue. If you verified the config I go back and look at permissions. I Try changing the port, usually I run mine on 5150 or 2112. Some times like one dude said earlier. Reinstall distro and start over. :(
On Tue, Nov 25, 2025 at 8:55 PM Gary saclug@garymcglinn.com wrote:
I started down this path because I won't always be able to physically access the server and I don't want the -R port to stop working, as it is the only way I can access the system to do anything, as it is behind a firewall.
If I just ran the ssh port forward in the background, I could get the famouns "pipe broken" error. I was hoping systemd would restart if this happened. I don't think it will, but I'll have to wait and see.
I have the Restart=on-failure. With Restart=always, it wouldn't run and seemed to be restarting a lot. But, I didn't see any restart limit errors in the logs, so I'm not exactly sure what was up.
Perhaps I'll look into the watchdog feature. I don't think this will get me anything though, since systemctl status thinks everything is fine and I have no reason to believe it wouldn't keep sending the necessary signal.
I'm thinking I'll have to implement my own watchdog feature, which is what I was hoping to avoid.
I had a lot of issues. I attributed these to systemd. Really, I think it was ssh. But it does seem that systemd is complex and might be a bit fragile. Lots of logging was generated but not visible. Gemini/Google suggest that these kind of "terminal configuration" issues can cause that problem. When things get fixed, the log entries are there, but it's not optimal.
On Tue, Nov 25, 2025 at 08:37:52PM -0800, Gary wrote:
Perhaps, but it seems to work intermittently and unpredictably. I
looked for contention on the port, but couldn't find any.
....So, I rebooted the client and restarted the systemd unit/service on
the server and everything works. Interestingly systemctl status for the unit showed that everything was OK before the restart, but nothing worked.
During the course of all this I learned, what is perhaps obvious, that
SSH does a lot of things at the terminal config level. If something in SSH terminates at an unexpected point, things can be messed up. Reset should fix this, but apparently not.
That's my story and I'm sticking to it LOL.
On Tue, Nov 25, 2025 at 06:23:03PM -0700, Linus Sphinx wrote:
It's always permissions. B-)
On Tue, Nov 25, 2025 at 3:27 PM Gary saclug@garymcglinn.com wrote:
So, I've put some more time into this. After learning a lot, I got
my ssh
-g -R port to connect using the systemd user unit. But, when I try
to use
the port, the connection is made, but hangs before the password
prompt. I
see lots of examples that look just like what I am doing that
apparently
work fine LOL.
I was just at the system I want to connect to, after my most recent changes, and ssh to my remote system and could connect back using -p
xxx
localhost. So the tunnel worked, at least once.
Now, I'm at the remote system. I try ssh -pxxx localhost, and it
just
hangs after the client sends the banner. I think this is same as
before.
So, when I run my ExecStart command from the command line, it
works. But
when running it inside a systemd unit, I have this issue.
It can't be firewall. It can't be network or DNS vs. straight IP.
It
can't be almost anything except systemd. But there is nothing in
the logs.
I'm thinking the next step is wiresharking everything. But that
sounds
painful.
Having written cron jobs in the past, I'm sort of used to this kind
of
mystery. Same with rc.local stuff, sort of. So it isn't the
ultimate
condemnation. But, like, it should work LOL.
Any thoughts?
On Tue, Nov 11, 2025 at 10:58:40PM -0800, Gary wrote:
I've felt that sisvinit is really all you need for a laptop or
desktop,
or possibly even a stand alone server.
But, after looking around, I took the path of least resistance and
began
using distros that use systemd.
Systemd has a lot of issues. It's monolithic. They went and built
something that is very flexible, and then used it a way that hardly utilizes it. It is way more than someone with a laptop, desktop, or
server
really needs. It solves a problem that is really only a problem for someone who has lots of systems to maintain each of which may have different configurations. Unfortunately, they didn't make this as
easy as
it should be; see not using flexibility previouly mentioned.
It does get around some of the awkwardness of rc.local, for
example. If
only I could get it to work. That was an issue with rc.local too,as
I
recall.
I'm thinking that if I get some time, I'll play around with it.
On Sat, Nov 08, 2025 at 07:09:03AM -0800, Charles Polisher wrote:
On 11/7/25 12:45, Brian E. Lavender wrote: > Install Fedora 43 from a clean install and systemd should work
fine.
Is
> Slackware still on non systemd? > > Brian Slackware is still running on sysvinit. Years of experience with Slackware, Fedora, Ubuntu, CentOS, Red Hat, FreeBSD, ... haven't has a problem with sysvinit, have spent dozens of hours "supporting" systemd. I haven't experienced any tangible benefit, but from previous posts, and private conversations on this topic, you do. Could it be because you're a laptop user? I believe that laptops would be ideal for me, except that the keyboards are always a non-starter. I haven't ever tried a laptop keyboard that didn't make my fingers feel retarded.
-- Chuck Polisher _______________________________________________ Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Good to know.
I think part of the issue is that my network is flaky. So, my script or unit file has to be more robust.
The port was down this morning. I added IgnoreSIGPIPE=no to the unit file and restarted the service. On restart systemctl status was green, but journalctl showed that the port forward was not established. So IgnoreSIGPIPE=no won't detect that.
Why this should default to yes is a bit of a mystery. man systemd.exec says it is because this signal is generally only useful in shell scripts. But, I would think that if my service gets one, I probably want to fix it.
In round two, I added ExitOnForwardFailed to my ssh command. This does force a restart by the unit if the port forward isn't established. And I added some keepalive options.
It's been working for 4 hours now, which is kind of a record.
Things are looking up.
I looked at autossh, but I think I'll see if what I have works. It does show that telling if ssh is actually functioning is a bit of an art. So, I guess I can't fault systemd too much.
On Tue, Nov 25, 2025 at 09:13:21PM -0800, Kevin Brisson wrote:
I use Ubuntu on my servers and have never had a systemd / ssh issue. Getting Tomcat to work with systemd can be tricky especially if your startup sh script gets complex. I’m going to guess you probably have a permissions issue. If you verified the config I go back and look at permissions. I Try changing the port, usually I run mine on 5150 or 2112. Some times like one dude said earlier. Reinstall distro and start over. :(
On Tue, Nov 25, 2025 at 8:55 PM Gary saclug@garymcglinn.com wrote:
I started down this path because I won't always be able to physically access the server and I don't want the -R port to stop working, as it is the only way I can access the system to do anything, as it is behind a firewall.
If I just ran the ssh port forward in the background, I could get the famouns "pipe broken" error. I was hoping systemd would restart if this happened. I don't think it will, but I'll have to wait and see.
I have the Restart=on-failure. With Restart=always, it wouldn't run and seemed to be restarting a lot. But, I didn't see any restart limit errors in the logs, so I'm not exactly sure what was up.
Perhaps I'll look into the watchdog feature. I don't think this will get me anything though, since systemctl status thinks everything is fine and I have no reason to believe it wouldn't keep sending the necessary signal.
I'm thinking I'll have to implement my own watchdog feature, which is what I was hoping to avoid.
I had a lot of issues. I attributed these to systemd. Really, I think it was ssh. But it does seem that systemd is complex and might be a bit fragile. Lots of logging was generated but not visible. Gemini/Google suggest that these kind of "terminal configuration" issues can cause that problem. When things get fixed, the log entries are there, but it's not optimal.
On Tue, Nov 25, 2025 at 08:37:52PM -0800, Gary wrote:
Perhaps, but it seems to work intermittently and unpredictably. I
looked for contention on the port, but couldn't find any.
....So, I rebooted the client and restarted the systemd unit/service on
the server and everything works. Interestingly systemctl status for the unit showed that everything was OK before the restart, but nothing worked.
During the course of all this I learned, what is perhaps obvious, that
SSH does a lot of things at the terminal config level. If something in SSH terminates at an unexpected point, things can be messed up. Reset should fix this, but apparently not.
That's my story and I'm sticking to it LOL.
On Tue, Nov 25, 2025 at 06:23:03PM -0700, Linus Sphinx wrote:
It's always permissions. B-)
On Tue, Nov 25, 2025 at 3:27 PM Gary saclug@garymcglinn.com wrote:
So, I've put some more time into this. After learning a lot, I got
my ssh
-g -R port to connect using the systemd user unit. But, when I try
to use
the port, the connection is made, but hangs before the password
prompt. I
see lots of examples that look just like what I am doing that
apparently
work fine LOL.
I was just at the system I want to connect to, after my most recent changes, and ssh to my remote system and could connect back using -p
xxx
localhost. So the tunnel worked, at least once.
Now, I'm at the remote system. I try ssh -pxxx localhost, and it
just
hangs after the client sends the banner. I think this is same as
before.
So, when I run my ExecStart command from the command line, it
works. But
when running it inside a systemd unit, I have this issue.
It can't be firewall. It can't be network or DNS vs. straight IP.
It
can't be almost anything except systemd. But there is nothing in
the logs.
I'm thinking the next step is wiresharking everything. But that
sounds
painful.
Having written cron jobs in the past, I'm sort of used to this kind
of
mystery. Same with rc.local stuff, sort of. So it isn't the
ultimate
condemnation. But, like, it should work LOL.
Any thoughts?
On Tue, Nov 11, 2025 at 10:58:40PM -0800, Gary wrote:
I've felt that sisvinit is really all you need for a laptop or
desktop,
or possibly even a stand alone server.
But, after looking around, I took the path of least resistance and
began
using distros that use systemd.
Systemd has a lot of issues. It's monolithic. They went and built
something that is very flexible, and then used it a way that hardly utilizes it. It is way more than someone with a laptop, desktop, or
server
really needs. It solves a problem that is really only a problem for someone who has lots of systems to maintain each of which may have different configurations. Unfortunately, they didn't make this as
easy as
it should be; see not using flexibility previouly mentioned.
It does get around some of the awkwardness of rc.local, for
example. If
only I could get it to work. That was an issue with rc.local too,as
I
recall.
I'm thinking that if I get some time, I'll play around with it.
On Sat, Nov 08, 2025 at 07:09:03AM -0800, Charles Polisher wrote: > On 11/7/25 12:45, Brian E. Lavender wrote: > > Install Fedora 43 from a clean install and systemd should work
fine.
Is
> > Slackware still on non systemd? > > > > Brian > Slackware is still running on sysvinit. Years of > experience with Slackware, Fedora, Ubuntu, CentOS, > Red Hat, FreeBSD, ... haven't has a problem with > sysvinit, have spent dozens of hours "supporting" > systemd. I haven't experienced any tangible benefit, > but from previous posts, and private conversations > on this topic, you do. Could it be because you're > a laptop user? I believe that laptops would be > ideal for me, except that the keyboards are always > a non-starter. I haven't ever tried a laptop > keyboard that didn't make my fingers feel retarded. > > -- > Chuck Polisher > _______________________________________________ > Lug-nuts mailing list -- lug-nuts@bigbrie.com > To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
I have this working well now. One of the issues clouding the water was that for some reason the SSH handshake hangs at one of the negotiation steps. Sometimes. The suggestion to add -o PubKeyAuthentication=no when connecting didn't do anything. When this occurs, if I just let the connection time out, I can connect when I try the next time. If I kill the connection, it will hang again the next time. Weird, somehow the sshd is acting up, but I guess I can live with that.
Recently the system I was connecting to with systemd went down. It kept trying to connect every 5 seconds for a couple of days before giving up. I updated the retry interval to 15 min. Everything nice and orderly.
I just used this service this morning and it worked as it should.
I'm thinking that I should think about moving most of my start up scripts to systemd. I have a few of these on various systems. And, some that I have been running manually are now ready. It gives me a better feeling than the old rc.local, which systemd still tries to mimic to support legacy stuff.
There is a place for bashrc and profile, but for anything more than setting environment variables, I'll take a look at moving to systemd. I like the fact that it will look around and restart things that go down or break for some reason.
After initially feeling that it was a bunch of unnecessary complexity, I've seen the light. I still don't care about speed, parallelization, or efficiency. But dependencies and the ability to restart things automatically are nice to have.
On Wed, Nov 26, 2025 at 11:52:54AM -0800, Gary wrote:
Good to know.
I think part of the issue is that my network is flaky. So, my script or unit file has to be more robust.
The port was down this morning. I added IgnoreSIGPIPE=no to the unit file and restarted the service. On restart systemctl status was green, but journalctl showed that the port forward was not established. So IgnoreSIGPIPE=no won't detect that.
Why this should default to yes is a bit of a mystery. man systemd.exec says it is because this signal is generally only useful in shell scripts. But, I would think that if my service gets one, I probably want to fix it.
In round two, I added ExitOnForwardFailed to my ssh command. This does force a restart by the unit if the port forward isn't established. And I added some keepalive options.
It's been working for 4 hours now, which is kind of a record.
Things are looking up.
I looked at autossh, but I think I'll see if what I have works. It does show that telling if ssh is actually functioning is a bit of an art. So, I guess I can't fault systemd too much.
On Tue, Nov 25, 2025 at 09:13:21PM -0800, Kevin Brisson wrote:
I use Ubuntu on my servers and have never had a systemd / ssh issue. Getting Tomcat to work with systemd can be tricky especially if your startup sh script gets complex. I’m going to guess you probably have a permissions issue. If you verified the config I go back and look at permissions. I Try changing the port, usually I run mine on 5150 or 2112. Some times like one dude said earlier. Reinstall distro and start over. :(
On Tue, Nov 25, 2025 at 8:55 PM Gary saclug@garymcglinn.com wrote:
I started down this path because I won't always be able to physically access the server and I don't want the -R port to stop working, as it is the only way I can access the system to do anything, as it is behind a firewall.
If I just ran the ssh port forward in the background, I could get the famouns "pipe broken" error. I was hoping systemd would restart if this happened. I don't think it will, but I'll have to wait and see.
I have the Restart=on-failure. With Restart=always, it wouldn't run and seemed to be restarting a lot. But, I didn't see any restart limit errors in the logs, so I'm not exactly sure what was up.
Perhaps I'll look into the watchdog feature. I don't think this will get me anything though, since systemctl status thinks everything is fine and I have no reason to believe it wouldn't keep sending the necessary signal.
I'm thinking I'll have to implement my own watchdog feature, which is what I was hoping to avoid.
I had a lot of issues. I attributed these to systemd. Really, I think it was ssh. But it does seem that systemd is complex and might be a bit fragile. Lots of logging was generated but not visible. Gemini/Google suggest that these kind of "terminal configuration" issues can cause that problem. When things get fixed, the log entries are there, but it's not optimal.
On Tue, Nov 25, 2025 at 08:37:52PM -0800, Gary wrote:
Perhaps, but it seems to work intermittently and unpredictably. I
looked for contention on the port, but couldn't find any.
....So, I rebooted the client and restarted the systemd unit/service on
the server and everything works. Interestingly systemctl status for the unit showed that everything was OK before the restart, but nothing worked.
During the course of all this I learned, what is perhaps obvious, that
SSH does a lot of things at the terminal config level. If something in SSH terminates at an unexpected point, things can be messed up. Reset should fix this, but apparently not.
That's my story and I'm sticking to it LOL.
On Tue, Nov 25, 2025 at 06:23:03PM -0700, Linus Sphinx wrote:
It's always permissions. B-)
On Tue, Nov 25, 2025 at 3:27 PM Gary saclug@garymcglinn.com wrote:
So, I've put some more time into this. After learning a lot, I got
my ssh
-g -R port to connect using the systemd user unit. But, when I try
to use
the port, the connection is made, but hangs before the password
prompt. I
see lots of examples that look just like what I am doing that
apparently
work fine LOL.
I was just at the system I want to connect to, after my most recent changes, and ssh to my remote system and could connect back using -p
xxx
localhost. So the tunnel worked, at least once.
Now, I'm at the remote system. I try ssh -pxxx localhost, and it
just
hangs after the client sends the banner. I think this is same as
before.
So, when I run my ExecStart command from the command line, it
works. But
when running it inside a systemd unit, I have this issue.
It can't be firewall. It can't be network or DNS vs. straight IP.
It
can't be almost anything except systemd. But there is nothing in
the logs.
I'm thinking the next step is wiresharking everything. But that
sounds
painful.
Having written cron jobs in the past, I'm sort of used to this kind
of
mystery. Same with rc.local stuff, sort of. So it isn't the
ultimate
condemnation. But, like, it should work LOL.
Any thoughts?
On Tue, Nov 11, 2025 at 10:58:40PM -0800, Gary wrote: > I've felt that sisvinit is really all you need for a laptop or
desktop,
or possibly even a stand alone server. > > But, after looking around, I took the path of least resistance and
began
using distros that use systemd. > > Systemd has a lot of issues. It's monolithic. They went and built something that is very flexible, and then used it a way that hardly utilizes it. It is way more than someone with a laptop, desktop, or
server
really needs. It solves a problem that is really only a problem for someone who has lots of systems to maintain each of which may have different configurations. Unfortunately, they didn't make this as
easy as
it should be; see not using flexibility previouly mentioned. > > It does get around some of the awkwardness of rc.local, for
example. If
only I could get it to work. That was an issue with rc.local too,as
I
recall. > > I'm thinking that if I get some time, I'll play around with it. > > > On Sat, Nov 08, 2025 at 07:09:03AM -0800, Charles Polisher wrote: > > On 11/7/25 12:45, Brian E. Lavender wrote: > > > Install Fedora 43 from a clean install and systemd should work
fine.
Is > > > Slackware still on non systemd? > > > > > > Brian > > Slackware is still running on sysvinit. Years of > > experience with Slackware, Fedora, Ubuntu, CentOS, > > Red Hat, FreeBSD, ... haven't has a problem with > > sysvinit, have spent dozens of hours "supporting" > > systemd. I haven't experienced any tangible benefit, > > but from previous posts, and private conversations > > on this topic, you do. Could it be because you're > > a laptop user? I believe that laptops would be > > ideal for me, except that the keyboards are always > > a non-starter. I haven't ever tried a laptop > > keyboard that didn't make my fingers feel retarded. > > > > -- > > Chuck Polisher > > _______________________________________________ > > Lug-nuts mailing list -- lug-nuts@bigbrie.com > > To unsubscribe send an email to lug-nuts-leave@bigbrie.com > > -- > -Gary > > It is a simple thing to make things complex, > a complex thing to make things simple. > > > > _______________________________________________ > Lug-nuts mailing list -- lug-nuts@bigbrie.com > To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-- -Gary
It is a simple thing to make things complex, a complex thing to make things simple.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-
Brian E. Lavender -
Charles Polisher -
Gary -
Kevin Brisson -
Linus Sphinx