Re: [systemd-devel] creating device nodes
Great, thanks - that seems to work:
/etc/tmpfiles.d/fuse.conf:
#Type Path Mode User Group Age Argument
c! /dev/fuse 0666 root root - 10:229
Mind you, I'm not entirely clear on what the '!' is for; I just put it
in because the manpage said it was a good idea :-)
Now to replicate that with ansible for my other containers ...
Cheers,
Richard
On 5/04/23 20:22, Mantas Mikulėnas wrote:
.device units do not mknod, they only represent existing state.
/dev/fuse is usually created through tmpfiles.d (which gets its
configuration via kmod-static-nodes.service).
# kmod static-nodes --format=tmpfiles
On Wed, Apr 5, 2023 at 11:13 AM Richard Hector <mailto:rich...@walnut.gen.nz>> wrote:
Hi all,
I want to create a device (/dev/fuse) in an LXC container. The kernel
bit works; I can mknod manually, but I'd rather use a systemd unit, and
make it a dependency of mounting filesystems from /etc/fstab.
It looks like .device units are supposed to be created automatically if
there's an appropriate udev rule with TAG+="systemd" - these lines
exists in /usr/lib/udev/rules.d/99-systemd.rules:
# Asynchronously mount file systems implemented by these modules as
soon
as they are loaded.
SUBSYSTEM=="module", KERNEL=="fuse", TAG+="systemd",
ENV{SYSTEMD_WANTS}+="sys-fs-fuse-connections.mount"
The comment seems to suggest it will cause the filesystems to be
mounted
when the device is created, which is kind of the reverse of what I'm
after. Do I need a different line?
Or do I need to create a .device unit file manually? I can't see much
info on doing that.
Cheers,
Richard
--
Mantas Mikulėnas
[systemd-devel] creating device nodes
Hi all,
I want to create a device (/dev/fuse) in an LXC container. The kernel
bit works; I can mknod manually, but I'd rather use a systemd unit, and
make it a dependency of mounting filesystems from /etc/fstab.
It looks like .device units are supposed to be created automatically if
there's an appropriate udev rule with TAG+="systemd" - these lines
exists in /usr/lib/udev/rules.d/99-systemd.rules:
# Asynchronously mount file systems implemented by these modules as soon
as they are loaded.
SUBSYSTEM=="module", KERNEL=="fuse", TAG+="systemd",
ENV{SYSTEMD_WANTS}+="sys-fs-fuse-connections.mount"
The comment seems to suggest it will cause the filesystems to be mounted
when the device is created, which is kind of the reverse of what I'm
after. Do I need a different line?
Or do I need to create a .device unit file manually? I can't see much
info on doing that.
Cheers,
Richard
[systemd-devel] non-existent unit instances
Hi all, Quoting from another thread: On 5/09/20 4:36 am, Lennart Poettering wrote: > Unit instances can be activated on-the-fly without further prepartion > or regsitration of the instance string or so. it's sufficient if the > template unit exists. Is that preventable? I have some instance names that are easily typoed. When I start one with the wrong name, it sticks around trying to restart for ever - or at least till I notice it or reboot - where I'm much rather get an error message and stop. For reference, this is with the openvpn-client@ (and maybe openvpn-server@) units in Debian buster. Some of the content was modified/overwritten by me, so it could well be a bug introduced by me. The typos are because my instances are based on hostname, which can contain '-' but not '_'. Instance names can apparently not contain '-', so I have to use '_' instead, but my muscle memory for my hostnames is strong. I don't know if this is a result of the way the units are written, or an inherent issue with systemd. Cheers, Richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'PIDFile=' warning and override.conf
On 27/08/20 1:43 am, Lennart Poettering wrote: > On Mi, 26.08.20 11:26, Richard Hector (rich...@walnut.gen.nz) wrote: > >> Hi all, >> >> I've got the common warning: >> >> /lib/systemd/system/fail2ban.service:12: PIDFile= references path below >> legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid → >> /run/fail2ban/fail2ban.pid; please update the unit file accordingly. >> >> I made the change in the relevant override.conf file, but that doesn't >> seem to work. Changing the 'real' one in /lib/systemd/system works. >> >> Is that how it's supposed to be? >> >> I'm using debian buster, with systemd package version 241-7~deb10u4 > > The warning is generated whenever a line is parsed that has the old > legacy path for this. If you later override it this doesn't change the > fact that earlier on the legacy path was parsed. Thanks, that makes sense. > There's not much point to try to fix that locally as user, it's a > warning only after all. In the end I made the changes in /lib/systemd/system/fail2ban.service (including using RuntimeDirectory). Using ansible, so it's easy to reapply. I use logcheck, and try to filter it down to what I need to see, but prefer to fix rather than filter where I can. Fixing in Debian would obviously be better, but given there are multiple existing bug reports, I'm not going to get into that battle. Thanks for your help. Cheers, Richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'PIDFile=' warning and override.conf
On 26/08/20 9:07 pm, Reindl Harald wrote: > > > Am 26.08.20 um 01:26 schrieb Richard Hector: >> Hi all, >> >> I've got the common warning: >> >> /lib/systemd/system/fail2ban.service:12: PIDFile= references path below >> legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid → >> /run/fail2ban/fail2ban.pid; please update the unit file accordingly. >> >> I made the change in the relevant override.conf file, but that doesn't >> seem to work. Changing the 'real' one in /lib/systemd/system works. >> >> Is that how it's supposed to be? >> >> I'm using debian buster, with systemd package version 241-7~deb10u4 > > better writ ebugreports so that these sloppy mainatiners wake up and > read their own logfiles before throwing packages to users - it's the > same on Fedora and i simple don't get it Which came first? The package that refers to the wrong directory, or the systemd version that changed the directory and/or started complaining about it? Debian stretch (systemd 232-25+deb9u12) doesn't complain. There are (at least) three bug reports for this in the Debian tracker already :-) But it's unlikely to be fixed in stable, because it's only a warning, and not a security issue (I assume). Not to mention a bunch of the 'sloppy maintainers' are probably grumpy that they had to learn and write systemd units in the first place, when they were happy with sysvinit :-) Anyway, at this point, I'm more interested in whether there's a bug in systemd, or whether it's intentional that I can't fix this in an override file rather than having to do it under /lib, where it's going to get overwritten with any package update. Or, of course, whether I'm just doing it wrong. In this case, doing it in /lib may be ok, because I'm doing it with ansible, so I can just re-run the play if I need to fix it again. Cheers, Richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'PIDFile=' warning and override.conf
On 26/08/20 12:10 pm, Chuck Wolber wrote: > You did not post your override.conf file for inspection, so it is hard > to tell. True, here it is (/etc/systemd/system/fail2ban.service.d/override.conf) [Service] ExecStartPre= ExecStartPre=/bin/mkdir -p /run/fail2ban PIDFile= PIDFile=/run/fail2ban/fail2ban.pid I didn't have the empty 'PIDFile=' line at first, and added it later. The 'ExecStartPre=' line I did have from the beginning. I wasn't sure if it was necessary, but from my understanding it wouldn't hurt. Those were the only two lines that mentioned /var/run/fail2ban; I figured I should update them in sync. > Did you remember to do a systemctl daemon-reload after you added your > override.conf? I did - that's what triggers the warning in /var/log/syslog (and presumably the journal, but syslog is what I'm more familiar with). Cheers, Richard > On Tue, Aug 25, 2020 at 4:27 PM Richard Hector <mailto:rich...@walnut.gen.nz>> wrote: > > Hi all, > > I've got the common warning: > > /lib/systemd/system/fail2ban.service:12: PIDFile= references path below > legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid → > /run/fail2ban/fail2ban.pid; please update the unit file accordingly. > > I made the change in the relevant override.conf file, but that doesn't > seem to work. Changing the 'real' one in /lib/systemd/system works. > > Is that how it's supposed to be? > > I'm using debian buster, with systemd package version 241-7~deb10u4 > > Cheers, > Richard > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > <mailto:systemd-devel@lists.freedesktop.org> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > > -- > *"Perfection must be reached by degrees; she requires the slow hand of > time." - Voltaire* > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] 'PIDFile=' warning and override.conf
Hi all, I've got the common warning: /lib/systemd/system/fail2ban.service:12: PIDFile= references path below legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid → /run/fail2ban/fail2ban.pid; please update the unit file accordingly. I made the change in the relevant override.conf file, but that doesn't seem to work. Changing the 'real' one in /lib/systemd/system works. Is that how it's supposed to be? I'm using debian buster, with systemd package version 241-7~deb10u4 Cheers, Richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.timer every X days?
On 29/07/20 4:13 am, Ian Pilcher wrote: > On 7/28/20 11:07 AM, Mantas Mikulėnas wrote: >> I'd create a single raidcheck.service that runs daily and calls a >> script that itself determines which device to check, e.g. >> /dev/md$[dayofyear % 16]. > > That is the approach that I'm taking, although it means a fair bit of > work. I need to parse a configuration file, do a bunch of date-related > math, etc., as I don't really want to hard-code the number of RAID > devices into a C program. Why not just record which one you've just finished, then next time, read that and do the next in the sequence? Richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
