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