1

Yesterday I had to change my Haproxy configuration and I noticed I couldn't restart it with systemctl. I had to launch it by hand.

Today I had to restart Docker and the same thing happened.

journalctl -xe after a systemctl restart haproxy:

-- Unit haproxy.service has begun starting up.
Aug 06 11:19:30 ns3038251 systemd[1]: haproxy.service: Control process exited, code=dumped status=7
Aug 06 11:19:30 ns3038251 systemd[1]: haproxy.service: Failed with result 'core-dump'.
Aug 06 11:19:30 ns3038251 systemd[1]: Failed to start HAProxy Load Balancer.
-- Subject: Unit haproxy.service has failed

And for Docker:

-- The start-up result is RESULT.
Aug 06 11:19:08 ns3038251 systemd[1]: containerd.service: Main process exited, code=dumped, status=7/BUS
Aug 06 11:19:08 ns3038251 systemd[1]: containerd.service: Failed with result 'core-dump'.

I know this is not a config file issue because both haproxy and containerd (and then dockerd) works when I run them in the console.

The problem is that internet doesn't give much information and I don't know what I can try to debug, this is on a distant server and I don't want to reboot in case it can't boot at all when started. By the way I didn't do anything recently, like updating

Thanks for any advice you can give me

Edit: I have been busy since posting the question, I logged back to the server minutes ago. I didn't do anything since and I returned to the same tmux window.

And now there is no problem systemctl restart haproxy or systemctl restart docker. I don't get what have happened here...

Improve this question
1
  • Since it's more often than not something simple, let me suggest checking that haproxy is enabled to start at boot. You probably already checked that, but on the off chance you haven't it's worth mentioning, if only to save hours of trying every esoteric possibility only to find it was something simple & feeling foolish you missed it.
    – llywrch
    Commented Aug 6, 2020 at 17:41

3 Answers 3

Reset to default
2

Try getting the process that is running ps aux | grep 'haproxy', then get this process PID, then kill it using kill -9 PID . Then try starting it again.

Improve this answer
1
  • I did it but same thing: core-dump
    – PeterHerb
    Commented Aug 6, 2020 at 13:32
0

If systemctl can't launch it, odds are it is one of a few things:

  1. Systemctl thinks it is running, due to some old PID file or a badly written launch script. Systemctl won't run two copies of something configured to only have one copy running.
  2. Systemctl's new security features cause an originally working launch script to fail. Recently (over the last year) many vendors have added symlink protections in systemctl, and if you symlink in certain files, systemctl won't follow the symlinks. This sounds odd, but it can prevent your system from getting "symlink hijacked".
  3. You use su or sudo to launch the service. This used to work, but this approach also opens security issues, so many vendors of Linux have changed systemctl to prefer "runas" as the user-shifting program. Runas does not suffer the weaknesses for the attacks that su or sudo can permit.

Of course, it could be something completely different; but, if you have any of these items in your service file, or the pid file, or the exec script launched by the service file, then you may have updated your software and discovered that a previously working service now has issues. That's likely because the previously working service was configured to launch in a less-than ideal way, and the configuration requires an update.

Improve this answer
1
  • systemctl doesn't do the launching. systemd does. And there is specific stuff in those log excerpts that this answer does not address, in terms of what steps one can take to diagnose a problem.
    – JdeBP
    Commented Aug 6, 2020 at 15:24
0

I don't know what I can try to debug

Your log is telling you that you have core dumps, somewhere. Find them, and look at what they tell you, as other people have elsewhere.

Go to the people whose program it is if necessary, or their support people, if you cannot understand what the core dump says. Have at minimum the outputs of systemctl show unitname and bt from a debugger (run against the coredump) in hand. They aren't telepathic and cannot know what relevant things are in your service unit configuration file, nor where to look in the program, if you do not tell them how you configured your service management and what your computer did.

Further reading

Improve this answer
1
  • For me the problem was systemd or systemctl, not the programs themselves. Thanks for mentionning coredumpctl though, this may come in handy. Sadly for the current case, as explained in my edit the problem automagically ""fixed"" itself so I'll never know. FWIW coredumpctl returns No coredumps found.
    – PeterHerb
    Commented Aug 8, 2020 at 18:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .