Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]
On Tue, 31 Dec 2019 04:37:10 -0500
Gene Heskett <gheskett@shentel.net> wrote:
> On Tuesday 31 December 2019 02:30:05 ghe wrote:
>
> > > On Dec 30, 2019, at 05:47 PM, Sven Hartge <sven@svenhartge.de>
> > > wrote:
> > >
> > > Please show the output of
> > >
> > > systemctl cat YOUR_SERVICE_UNIT
> > >
> > > This will show all additions and overrides to the unit.
> >
> > root@test:~# systemctl cat ipfilter
> > # /usr/lib/systemd/system/ipfilter.service
> > [Unit]
> > Description=packetFilter
> >
> > [Service]
> > ExecStart=/etc/ipfilterfiles/ipfilter.sh on
> > ExecStop=/etc/ipfilterfiles/ipfilter.sh off
> >
> > [Install]
> > WantedBy=multi-user.target
> >
> > > Your shell script isn't really daemon, so it is normal to not stay
> > > running after it setup the iptables rules.
> >
> > I guess I misunderstood the term 'daemon.' I thought it was just a
> > piece of software that, when run, stays run until it's through --
> > when it's started at boot and has no exit, hangs around in the
> > background doing stuff. Unless somebody tells it to stop.
> >
> > This code has, under the old init system, been thinking it's a
> > daemon for a couple decades now. But you're right. On other systemd
> > computers, I have to start my local firewall by hand, like I have to
> > with BIND on the DNS server.
> >
> > > I think your unit is missing the following:
> > >
> > > ,----
> > >
> > > | [Service]
> > > | Type=oneshot
> > > | RemainAfterExit=yes
> > >
> > > `----
> >
> > That makes sense. I'll insert those lines and see what happens.
> >
> > I knew it'd be trivial when it came to light what I was missing.
> > Thanks a lot.
> >
> > (grumble, grumble, systemd, grumble, grumble)
> >
> > >> And how did that file get in /usr? When I wrote it, it was in
> > >> /lib/systemd/system.
> > >
> > > usr-merge is the keyword here.
> >
> > What's that? I never heard of that before, and I certainly didn't
> > ask for it. One of the reasons I run Debian was that the config
> > stuff is all in /etc. And, it goes without saying, stays there.
> >
> > As I said before, (grumble, grumble, systemd, grumble, grumble). It
> > seems to be pretty nicely done system code, but with an absolutely
> > abominable user interface. So far, I know of systemd dirs in /lib,
> > /etc, and /usr. That's no way to run a *nix railroad.
> >
> +100 (or more)
>
> > While I have you on the hook, Sven, how/where did you get your
> > systemd knowledge? I've looked around, and I haven't seen any
> > mention of what you just told me.
>
> I had that same didn't start after a reboot problem, but found this
> script started iptables ok when executed by hand as ./start-iptables
> while root in the /etc/iptables dir.
>
> #!/bin/bash
> iptables-restore <saved-rules
>
> And whenever I add a new rule, I resave the saved-rules with this
>
> #!/bin/bash
> iptables-save >saved-rules
>
> A executed from /etc/iptables with ./iptables-saveem
>
> It seems to me, that if iptables has been intalled, there ought to be
> a start script in /etc/init.d, or someplace in the /etc/systemd path,
> but there is not such a critter in either path (nothing in /usr,
> but /lib/systemd has 100 or so files) in this stretch install.
>
> This works, but leaves me open until I get around to starting it, so
> I doubt its the approved method. IMO it ought to be the first active
> line in the ifup script so its active before the net is brought up.
>
Does iptables-persistent work for you?
I made my own pseudo-daemon before this existed, stealing a LFS
skeleton, allowing multiple rulesets for various environments.
--
Joe
Reply to: