[systemd-devel] mount units
All HI systemdgroup, i found a special behavior with btrfs and systemd mount. BTRFS is partly diverting its "subvolume" technics from the functional intended usage: A "subvolume" is usable like an directory. The documentation indicates such possibility, also. E.g.: The User can replace the recursive delete command on directories with a btrfs command. https://www.oracle.com/technical-resources/articles/it-infrastructure/admin-advanced-btrfs.html Triggered by this suggestion i tried to use a btrfs subvolume as mount directory inside of an systemd mount unit. And, spring success on myself. Then, came a question into being. Appears a btrfs subvolume to the system mount service with the aspect of a directory, and btrfs subvolume features a not capable anymore? (Owing to, btrfs is falling back into a classical directory...) Or: both systems are lying next to each other without interference and with full feature set. E.g. snapshots with btrfs or changed directory mode through systemd after mounting. sincerely -kefko -- Wonderful vim doku: When a mapping triggers itself, it will run forever WEB www.johannes-koehler.de
Re: [systemd-devel] Antw: [EXT] Re: Q: "Industry Standard" unit files
On Tue, Aug 3, 2021 at 1:28 PM Ulrich Windl wrote: > Thanks for having a look! So it seems not as broken as I was afraid. > You are right that the service was written for inetd originally, and one of > the problems found with systemd is that the process ends with varying exit > codes (mostly 1 and 3) that systemd considers to be not successful. > See SuccessExitStatus in man systemd.service
Re: [systemd-devel] [EXT] Re: Q: "Industry Standard" unit files
On Tue, Aug 3, 2021 at 1:28 PM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > >>> Mantas Mikulenas schrieb am 03.08.2021 um 11:44 in > Nachricht > : > > On Tue, Aug 3, 2021, 11:36 Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> > > wrote: > > > >> Hi! > >> > >> I'm not into socket units, but maybe one one is could have a look at the > >> unit files shown in https://serverfault.com/q/1070757/407952. Those > files > >> are from a commercial product (Backup Software) > >> I wonder if these look OK, or (what I think) are quite incomplete. > >> > > > > Looks mostly OK to me. > > > >> > > A dependency on network is not needed for sockets with wildcard binds > (i.e. > > just port, no specific IP address). These will always succeed. > > > > The service doesn't need a general network dep either, if you've > received a > > connection then the network is usually already up. > > > > Dependency on local-fs is implied in DefaultDependencies, *I think,* so > you > > don't need to explicitly add it. Although maybe > > RequiresMountsFor=/var/opt/omni would be useful. > > > > I wouldn't expect the vendor to include a dep on remote-fs by default. > It's > > up to the admin to decide this – locally adding dependencies is quite a > bit > > easier than locally removing unwanted ones (I really wish unit files had > a > > -= operator, but.) Having things depend on NFS when they don't actually > > need it is annoying. > > > > On the other hand, I would *remove* some options – that PIDFile= is > > redundant in general, and just outright makes no sense for a templated@ > > service to use a non-templated pidfile path. The KillMode=process is also > > somewhat dubious. > > > > PartOf=omni.service doesn't seem like it would work, as an Accept=yes > > socket will indeed use omni@.service (one instance per connection, not a > > single long-running daemon – this very much looks like a direct > conversion > > from inetd-based service to systemd). I'd remove it here. > > > > Similarly, the WantedBy= in omni@.service is nonsensical – inetd > > per-connection services can't be started on boot, there's no connection > to > > attach them to... This kind of service has to be started by the socket, > not > > through `systemctl enable`. > > Thanks for having a look! So it seems not as broken as I was afraid. > You are right that the service was written for inetd originally, and one of > the problems found with systemd is that the process ends with varying exit > codes (mostly 1 and 3) that systemd considers to be not successful. > The mapping of exit codes can be overridden -- if the process itself considers 1 and 3 to be successful, then "SuccessExitStatus=0 1 3" would help. Prefixing the command with a "-" (as in "ExecStart=-/opt/foo") is also an option, if you want to ignore *all* exit codes; many inetd-converted services do this to avoid accumulating failed instances (e.g. after botnet probes). -- Mantas Mikulėnas
[systemd-devel] Antw: [EXT] Re: Q: "Industry Standard" unit files
>>> Mantas Mikulenas schrieb am 03.08.2021 um 11:44 in Nachricht : > On Tue, Aug 3, 2021, 11:36 Ulrich Windl > wrote: > >> Hi! >> >> I'm not into socket units, but maybe one one is could have a look at the >> unit files shown in https://serverfault.com/q/1070757/407952. Those files >> are from a commercial product (Backup Software) >> I wonder if these look OK, or (what I think) are quite incomplete. >> > > Looks mostly OK to me. > >> > A dependency on network is not needed for sockets with wildcard binds (i.e. > just port, no specific IP address). These will always succeed. > > The service doesn't need a general network dep either, if you've received a > connection then the network is usually already up. > > Dependency on local-fs is implied in DefaultDependencies, *I think,* so you > don't need to explicitly add it. Although maybe > RequiresMountsFor=/var/opt/omni would be useful. > > I wouldn't expect the vendor to include a dep on remote-fs by default. It's > up to the admin to decide this – locally adding dependencies is quite a bit > easier than locally removing unwanted ones (I really wish unit files had a > -= operator, but.) Having things depend on NFS when they don't actually > need it is annoying. > > On the other hand, I would *remove* some options – that PIDFile= is > redundant in general, and just outright makes no sense for a templated@ > service to use a non-templated pidfile path. The KillMode=process is also > somewhat dubious. > > PartOf=omni.service doesn't seem like it would work, as an Accept=yes > socket will indeed use omni@.service (one instance per connection, not a > single long-running daemon – this very much looks like a direct conversion > from inetd-based service to systemd). I'd remove it here. > > Similarly, the WantedBy= in omni@.service is nonsensical – inetd > per-connection services can't be started on boot, there's no connection to > attach them to... This kind of service has to be started by the socket, not > through `systemctl enable`. Thanks for having a look! So it seems not as broken as I was afraid. You are right that the service was written for inetd originally, and one of the problems found with systemd is that the process ends with varying exit codes (mostly 1 and 3) that systemd considers to be not successful. Regards, Ulrich > >>
Re: [systemd-devel] Q: "Industry Standard" unit files
On Tue, Aug 3, 2021, 11:36 Ulrich Windl wrote: > Hi! > > I'm not into socket units, but maybe one one is could have a look at the > unit files shown in https://serverfault.com/q/1070757/407952. Those files > are from a commercial product (Backup Software) > I wonder if these look OK, or (what I think) are quite incomplete. > Looks mostly OK to me. > A dependency on network is not needed for sockets with wildcard binds (i.e. just port, no specific IP address). These will always succeed. The service doesn't need a general network dep either, if you've received a connection then the network is usually already up. Dependency on local-fs is implied in DefaultDependencies, *I think,* so you don't need to explicitly add it. Although maybe RequiresMountsFor=/var/opt/omni would be useful. I wouldn't expect the vendor to include a dep on remote-fs by default. It's up to the admin to decide this – locally adding dependencies is quite a bit easier than locally removing unwanted ones (I really wish unit files had a -= operator, but.) Having things depend on NFS when they don't actually need it is annoying. On the other hand, I would *remove* some options – that PIDFile= is redundant in general, and just outright makes no sense for a templated@ service to use a non-templated pidfile path. The KillMode=process is also somewhat dubious. PartOf=omni.service doesn't seem like it would work, as an Accept=yes socket will indeed use omni@.service (one instance per connection, not a single long-running daemon – this very much looks like a direct conversion from inetd-based service to systemd). I'd remove it here. Similarly, the WantedBy= in omni@.service is nonsensical – inetd per-connection services can't be started on boot, there's no connection to attach them to... This kind of service has to be started by the socket, not through `systemctl enable`. >
[systemd-devel] Q: "Industry Standard" unit files
Hi! I'm not into socket units, but maybe one one is could have a look at the unit files shown in https://serverfault.com/q/1070757/407952. Those files are from a commercial product (Backup Software) I wonder if these look OK, or (what I think) are quite incomplete. Regards, Ulrich
[systemd-devel] Best way to reapply link configurations?
This is my first time using link files and I want to be able to reapply a link configuration if, for example, RxBufferSize= changes. For network and netdev, there is `networkctl reconfigure ` but there wasn't anything as obvious in `udevadm`. I've found some ways to make it work but I wanted to see if one was particularly better (or if there was a simpler alternative). For example the following commands worked: `echo add > /sys/class/net/eth0/uevent` `udevadm trigger --action=add /sys/class/net/eth0` `udevadm test /sys/class/net/eth0` Thanks, Anita
