[systemd-devel] systemd-inhibit don't work
well, i would expect that the reboot in the scond ssh-session is refused... [root@master:~]$ /usr/bin/systemd-inhibit --what=shutdown --who=root --why="Backup in progress" --mode=block sleep 600 [root@master:~]$ /usr/bin/systemd-inhibit; systemctl reboot WHO UID USER PID COMMWHAT WHYMODE root 0 root 569 systemd-inhibit shutdown Backup in progress block 1 inhibitors listed. [root@master:~]$ Connection to master.thelounge.net closed by remote host. Connection to master.thelounge.net closed. [harry@srv-rhsoft:~]$ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-inhibit don't work
On Mo, 10.08.20 15:05, Reindl Harald (h.rei...@thelounge.net) wrote: > well, i would expect that the reboot in the scond ssh-session is > refused... > > [root@master:~]$ /usr/bin/systemd-inhibit --what=shutdown --who=root > --why="Backup in progress" --mode=block sleep 600 > > [root@master:~]$ /usr/bin/systemd-inhibit; systemctl reboot > WHO UID USER PID COMMWHAT WHYMODE > root 0 root 569 systemd-inhibit shutdown Backup in progress block > > 1 inhibitors listed. > [root@master:~]$ Connection to master.thelounge.net closed by remote host. > Connection to master.thelounge.net closed. > [harry@srv-rhsoft:~]$ Root is almighty on UNIX. This also means it has the privilege to ignore inhibitors, and thta's what you are seeing here. There is a github issue filed asking for some mechanism to extend inhibitors so that root can't trivially override it, but so far this hasn't been implemented. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No signal sent to stop service
Hi David. On Thu, Aug 06, 2020 at 01:59:03PM +1200, David Cunningham wrote: > The systemd file is as below, and we've confirmed that the PIDFile contains > the correct PID when the stop is attempted. Would anyone have any > suggestions on how to debug this? Thank you in advance. Is the given process running under the expected cgroup (check /proc/$PID/cgroup)? Note that the default KillMode=control-group would not necessarily kill the PIDFile process (systemd.kill (5)). HTH, Michal signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No signal sent to stop service
On Do, 06.08.20 13:59, David Cunningham (dcunning...@voisonics.com) wrote: > Hello, > > I'm developing a service called product_routed which is managed by systemd. > The service can normally be stopped with "service product_routed stop" or > "systemctl stop product_routed", however for some reason after the service > has been running for a while (a few days or more) the stop command no > longer works. Can anyone help me find why? > > When the application stop works initially (for the first day or two) we see > a TERM signal sent to the application, as confirmed by logging in the > application itself (which is written in perl), and is reported by "strace > -p -e 'trace=!all'". However once the problem starts no signal is > sent to the application at all when "service product_routed stop" or > "systemctl stop product_routed" is run. Note that on systemd for a unit that is already stopped issuing another "systemctl stop" is a NOP and doesnt result in another SIGTERM to be sent So, when you issue your second "systemctl stop", is the service actually running in systemd's eyes? (i.e. what does "systemctl status" say about the service?) > The systemd file is as below, and we've confirmed that the PIDFile contains > the correct PID when the stop is attempted. Would anyone have any > suggestions on how to debug this? Thank you in advance. > > # cat /etc/systemd/system/product_routed.service > [Unit] > Description=Product routing daemon > After=syslog.target network.target mysql.service > > [Service] > Type=forking > ExecStart=/opt/product/current/bin/routed > PIDFile=/var/run/product/routed.pid > Restart=on-abnormal > RestartSec=1 > LimitSTACK=infinity > LimitNOFILE=65535 > LimitNPROC=65535 > > [Install] > WantedBy=multi-user.target Please provide the "sytemctl status" output when this happens. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem understanding output of systemd-cgtop
Hello.
On Mon, Aug 03, 2020 at 10:31:28AM +0200, Ulrich Windl
wrote:
> Why is systemd-cgtop outputting much less slices than systemd-cgls
> does? Specifically I don't see the slice for the process I'm examining
> ("system-iotwatch.slice"). systemd-cgls shows it with three services.
systemd-cgls lists (full) hierarchy maintained by systemd for process
tracking.
The available controller hierarchies can be more shallow though as
they're maintained based on configuration needs. And systemd-cgtop shows
information from the controller hierarchies.
> Also, when using "systemd-cgtop --depth 1", I get this output:
> Control GroupTasks %CPU Memory Input/s
> Output/s
> /-1.1 564.7M-
> -
> /init.scope 1 ---
> -
> /system.slice 82 ---
> -
> /user.slice 18 ---
> -
>
>
> Does that output mean /init.scope, /system.slice, and /user.slice all
> don't need any CPU and memory, while only / does?
You only see aggregated consumption of everything under the root*.
because apparently no unit specified fine-grained CPU or memory
accounting
> So why does / have CPU and memory usage, while all others don't?
The tasks count under the root is missing since it's not implemented in
v228, the IO may be missing because no IO is taking place at the
moment.
Regards,
Michal
*) That is usage of all units under the root slice + tasks residing in
the root cgroup (typically only kernel threads, these aren't associated
with any unit and their accounting may be special).
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-repart with volatile root
Is anyone able to help with this issue ? Is this even supported/supposed to work, or expected to fail ? I was hoping to use repart because the system I have to add a partition to is litterally 5000 km away, but so far this completely fails. Any help would be appreciated On Tue Jul 28, 2020 at 7:38 PM CEST, Xogium wrote: > I am still totally unable to make use of repart when the root is > volatile... Is > this intended, or not ? I know volatile-root service changes where the > sysroot.mount ends up, for overlayfs, but this prevent repart from > working > because it can't find the underlying root block device anymore but only > the > overlay. > > It seems so, at least. This is my only theory for as to why it would > print > 'failed to discover root block device'. > Any help / ideas are welcome > > On Fri Jul 17, 2020 at 4:38 PM CEST, Xogium wrote: > > Hi, > > as the subject says, I am trying to use repart to add a partition on a > > block > > device, from inside the initramfs. I also make use of overlayfs via > > systemd-volatile-root to make it possible to write temporarily on the > > root device. However it appears that systemd-repart and > > systemd-volatile-root are both ran in parallel: http://ix.io/2rRi > > This results in repart failing to find the root block device. > > Would there be any way to have repart ran before systemd-volatile-root, > > such > > that it has time to finish modifying the real block device ? Adding > > systemd-volatile-root on the Before= line in systemd-repart.service via > > an > > override is not enough since both units are of type simple. It is > > started before > > the volatile root unit, but they both ultimately end up running in > > parallel once > > again. > > ___ > > 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
Re: [systemd-devel] systemd-repart with volatile root
On Fr, 17.07.20 14:38, Xogium (cont...@xogium.me) wrote: > Hi, > as the subject says, I am trying to use repart to add a partition on a block > device, from inside the initramfs. I also make use of overlayfs via > systemd-volatile-root to make it possible to write temporarily on the > root device. However it appears that systemd-repart and > systemd-volatile-root are both ran in parallel: http://ix.io/2rRi > This results in repart failing to find the root block device. > Would there be any way to have repart ran before systemd-volatile-root, such > that it has time to finish modifying the real block device ? Adding > systemd-volatile-root on the Before= line in systemd-repart.service via an > override is not enough since both units are of type simple. It is started > before > the volatile root unit, but they both ultimately end up running in parallel > once > again. This is supposed to just work, and if it doesn't it's a bug. It appears s-v-r.s should have an After=s-r.s but currently does not. The fix should be easy: just add it to the unit file. Event better, prep a PR and submit it upstream and we'll merge it. Alternatively, file an issue, and we'll look into it, eventually (or is there already one filed?). Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-repart with volatile root
On Mo, 10.08.20 19:36, Lennart Poettering (lenn...@poettering.net) wrote: > On Fr, 17.07.20 14:38, Xogium (cont...@xogium.me) wrote: > > > Hi, > > as the subject says, I am trying to use repart to add a partition on a block > > device, from inside the initramfs. I also make use of overlayfs via > > systemd-volatile-root to make it possible to write temporarily on the > > root device. However it appears that systemd-repart and > > systemd-volatile-root are both ran in parallel: http://ix.io/2rRi > > This results in repart failing to find the root block device. > > Would there be any way to have repart ran before systemd-volatile-root, such > > that it has time to finish modifying the real block device ? Adding > > systemd-volatile-root on the Before= line in systemd-repart.service via an > > override is not enough since both units are of type simple. It is started > > before > > the volatile root unit, but they both ultimately end up running in parallel > > once > > again. > > This is supposed to just work, and if it doesn't it's a bug. > > It appears s-v-r.s should have an After=s-r.s but currently does > not. The fix should be easy: just add it to the unit file. Event > better, prep a PR and submit it upstream and we'll merge it. > > Alternatively, file an issue, and we'll look into it, eventually (or > is there already one filed?). Ah, well, I just prepped the PR myself: https://github.com/systemd/systemd/pull/16707 You should be able to make the same change locally, but make sure that you rebuild your initrd so that it includes the updated unit file. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem understanding output of systemd-cgtop
On Mo, 03.08.20 10:31, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> Hi!
>
> While examining a scheduling problem that might have resulted from
> restrictions imposed by cgroups, I examined my machine using systemd-cgtop
> and systemd-cgls (systemd-228-157.12.5.x86_64 of SLES12).
> Among the things I don't understand are:
> Why is systemd-cgtop outputting much less slices than systemd-cgls does?
> Specifically I don't see the slice for the process I'm examining
> ("system-iotwatch.slice"). systemd-cgls shows it with three services.
You need to enable resource accounting for data to be shown for a
unit. Either per unit with MemoryAccounting=, CPUAccounting=,
IOAccounting= and so on, see systemd.resource-control(5). Or globally
with DefaultMemoryAccounting=, … in systemd-system.conf.
By default the accounting is not enabled on old kernels since it's
slow there. On newer kernels we enable some accounting by default, but
not all.
For the root cgroup we can use the system resource accounting, which
is available always, hence you always see useful data for the first
line, regardless if per-unit accounting is on or not.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ConditionPathExists vs mount unit
On Mo, 10.08.20 19:46, Böszörményi Zoltán (zbos...@pr.hu) wrote: > Is there a way to describe optional mounts via such Conditions* options? No. .mount units automatically gain dependencies on the devices they are mounted from. Only after all dependencies are fulfilled (i.e. the backing device showed up) the mount is executed, and as first step of that the conditions are checked, i.e. much too late for your case. My recommendation to you: write a generator, see systemd.generator(7) for details. The existing systemd-gpt-auto-generator(8) does pretty much what you want to do already, maybe use that as inspiration. It only supports GPT disk images however, and it auto-detects /var/ partitions only since v245. Generators run very very early at boot and generate units and dependencies. this is where you should genreate your var.mount depending on the partition table. But note you have to implement that very carefuly, and do raw disk accesses, since udev and such is not running that early, nor do you even have the guarantee the kernel itself noticed your extra partition or not yet. The only guarantee you get is that the root partition was already found, everything else might happen concurrently. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit timer
On So, 09.08.20 15:56, Dave Howorth (syst...@howorth.org.uk) wrote: > Is there anywhere that explains the rationale for systemd timers? Probably somewhere in the git logs. > What's their USP? Why was it necessary to invent the facility? It kinda makes sense to invoke cronjobs the same way as any other piece of system code in userspace: as a service, so that you can take benefit of deps management, priv handling, logging, sandboxing and so on, so that you can run stuff either manually or by timers or by any other kind of activation, and so on, and it always ends up in exactly one instance. And there's tons of other stuff too. i.e. it unifies how system programs are invoked, and that's a good thing. it turns time-based activation into "just another type of activation". Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit timer
On So, 09.08.20 00:20, Vini Harimoorthy (vini6...@gmail.com) wrote: > Hi Team, > > > Is there a way to specify the "start date & time" of the timer unit with > calendar timer ? > > For example, the below timer units runs every weekly from the service is > activated.My requirement is that I need to run the timer unit only after > the 10th month i.e."2020-10-1" We currently have no nice mechanism for that. You can hack something up though: define three timer units: the first one runs the service the first time, the second one starts it then regularly. And the third one then stops the second one. e.g. first-start.timer: [Timer] OnCalendar=2020-10-1 Unit=myservice.service regular-start.timer: [Timer] OnCalendar=weekly Unit=myservice.service myservice.service: [Unit] Wants=regular-start.timer final.timer [Service] … final.timer [Timer] OnCalendar=2021-8-1 Unit=stop-final.service stop-final.service [Service] ExecStart=/usr/bin/systemctl --no-block stop final.timer Type=oneshot Or something like that. You get the idea. That said, I think adding a new concept of NotBefore= and NotAfter= to .timer units would make a ton of sense. Please file an RFE issue on github asking for this to be added. With a concept like this we could then just have a new syntax: [Timer] NotBefore=2020-10-1 NotAfter=2021-8-1 OnCalendar=weekly I think such an addition would make a ton of sense. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does automatic boot assessment work for Type #2 EFI Unified Kernel Images?
On Do, 06.08.20 01:14, Arian Van Putten (ar...@wire.com) wrote: > Hey List, > > I am reading > https://systemd.io/BOOT_LOADER_SPECIFICATION/ > and > https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ > > I want to use Type 2 unified images because of SecureBoot. But I want a > 2-partition model a-la CoreOS, where I rollback when the node isn't > healthy. I wanted to use automatic boot assessment to implement this > mechanism. Where I have 2 EFI images in $BOOT/loader/entries/; one loading > the first partition in its cmdline; and the other loading the second > partition in its cmdline. But then I noticed that > https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ only talks about files in > $BOOT/loader/entries/ and not $boot/EFI/Linux/ > > Does this mean automatic boot assessment doesn't work for Type #2 entries? > Or will it work for that as well if I name my EFI images in a similar > naming scheme as the entries in $BOOT/loader/entries > > If not; is there a good reason why not and is it something that is worth > implementing? It should already just work. If it doesn't it would be a bug. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd and interface names
Greetings, I am using systemd-networkd and I am wondering how/why the interface names get chosen. Scenario: I am expecting an interface name to be enp1s0. Instead I get eth1. It appears that eth1 is being referenced in things like: /etc/default/isc-dhcp-server /etc/default/minissdpd If I change those instances of eth1 to enp1s0, then the interface rename happens as expected: # dmesg | grep eth1 [1.751611] tg3 :01:00.0 eth1: Tigon3 [partno(BCM95722A2202G) rev a200] (PCI Express) MAC address 00:10:18:59:c3:6f [1.751613] tg3 :01:00.0 eth1: attached PHY is 5722/5756 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) [1.751614] tg3 :01:00.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] [1.751616] tg3 :01:00.0 eth1: dma_rwctrl[7618] dma_mask[64-bit] [ 17.763317] tg3 :01:00.0 enp1s0: renamed from eth1 Is this expected behavior with the kernel, udev, etc.? Thanks for any help! -m ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit timer
On Mon, 10 Aug 2020 20:21:51 +0200 Lennart Poettering wrote: > On So, 09.08.20 15:56, Dave Howorth (syst...@howorth.org.uk) wrote: > > > Is there anywhere that explains the rationale for systemd timers? > > Probably somewhere in the git logs. Thanks, Lennart. I'll happily poke through the logs to try to find it, but I've no idea where to start. A starting point URL for the logs would be helpful to me. > > What's their USP? Why was it necessary to invent the facility? > > It kinda makes sense to invoke cronjobs the same way as any other > piece of system code in userspace: as a service, so that you can take > benefit of deps management, priv handling, logging, sandboxing and so > on, so that you can run stuff either manually or by timers or by any > other kind of activation, and so on, and it always ends up in exactly > one instance. And there's tons of other stuff too. > > i.e. it unifies how system programs are invoked, and that's a good > thing. it turns time-based activation into "just another type of > activation". Most of that has gone over my head so some examples would probably help me to understand. Perhaps they're in the git logs? But I'm not normally running system code in cronjobs. I usually run either scripts I have written myself, or backup commands and the like. If I wanted to run a service, presumably I could just write a 'manual' invocation as a cron or at job? I'm not seeing the big imperative to create another new bunch of code to learn and maintain. I expect I'm blind. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-inhibit don't work
On Mon, 2020-08-10 at 15:37 +0200, Lennart Poettering wrote: > On Mo, 10.08.20 15:05, Reindl Harald (h.rei...@thelounge.net) wrote: > > > well, i would expect that the reboot in the scond ssh-session is > > refused... > > > > [root@master:~]$ /usr/bin/systemd-inhibit --what=shutdown --who=root > > --why="Backup in progress" --mode=block sleep 600 > > > > [root@master:~]$ /usr/bin/systemd-inhibit; systemctl reboot > > WHO UID USER PID COMMWHAT WHYMODE > > root 0 root 569 systemd-inhibit shutdown Backup in progress block > > > > 1 inhibitors listed. > > [root@master:~]$ Connection to master.thelounge.net closed by remote host. > > Connection to master.thelounge.net closed. > > [harry@srv-rhsoft:~]$ > > Root is almighty on UNIX. This also means it has the privilege to > ignore inhibitors, and thta's what you are seeing here. > > There is a github issue filed asking for some mechanism to extend > inhibitors so that root can't trivially override it, but so far this > hasn't been implemented. > > Lennart > > -- > Lennart Poettering, Berlin Hi, Current plan is to work on that sometimes next month and submit an RFC, unless objections are raised on the RFE or someone else beats me to it of course. (for reference, the RFE is https://github.com/systemd/systemd/issues/16454 ) -- Kind regards, Luca Boccassi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd and interface names
That seems to be working as expected. The initial, kernel-assigned name is always going to be an incrementing eth#, wlan#, or something similar. It's up to the userspace (i.e. udev) to rename it to something custom. However, interfaces can only be renamed while they're *not* up, otherwise the kernel refuses it with EBUSY. If some program brings eth1 up without waiting for udev to finish rule processing, renaming will fail and it'll just remain eth1. On Mon, Aug 10, 2020, 21:45 Matt Zagrabelny wrote: > Greetings, > > I am using systemd-networkd and I am wondering how/why the interface names > get chosen. > > Scenario: > > I am expecting an interface name to be enp1s0. Instead I get eth1. > > It appears that eth1 is being referenced in things like: > /etc/default/isc-dhcp-server > /etc/default/minissdpd > > If I change those instances of eth1 to enp1s0, then the interface rename > happens as expected: > > # dmesg | grep eth1 > [1.751611] tg3 :01:00.0 eth1: Tigon3 [partno(BCM95722A2202G) rev > a200] (PCI Express) MAC address 00:10:18:59:c3:6f > [1.751613] tg3 :01:00.0 eth1: attached PHY is 5722/5756 > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) > [1.751614] tg3 :01:00.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] > ASF[0] TSOcap[1] > [1.751616] tg3 :01:00.0 eth1: dma_rwctrl[7618] dma_mask[64-bit] > [ 17.763317] tg3 :01:00.0 enp1s0: renamed from eth1 > > Is this expected behavior with the kernel, udev, etc.? > > Thanks for any help! > > -m > ___ > 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
Re: [systemd-devel] systemd unit timer
On 8/10/2020 12:19 PM, Dave Howorth wrote: Most of that has gone over my head so some examples would probably help me to understand. Perhaps they're in the git logs? The key word is "activation". Modern systems are event-driven. Events include hardware plugging in, powering up, another program starting, or a point on the calendar. systemd launches programs when events happen. That's activation. In the past, activation was handled by lots of independent subsystems (initscripts, xinetd, cron) and they had the potential to conflict. Now it's all handled in one place and one way. Which eliminates a lot of duplication of effort. It means you don't need to fix the same bug in multiple subsystems. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit timer
On Mon, 2020-08-10 at 20:19 +0100, Dave Howorth wrote:
> On Mon, 10 Aug 2020 20:21:51 +0200
> Lennart Poettering wrote:
> > i.e. it unifies how system programs are invoked, and that's a good
> > thing. it turns time-based activation into "just another type of
> > activation".
>
> Most of that has gone over my head so some examples would probably help
> me to understand. Perhaps they're in the git logs?
>
> But I'm not normally running system code in cronjobs. I usually run
> either scripts I have written myself, or backup commands and the like.
Even many of the simplest scripts will most likely benefit from basic
systemd unit functionality like having correct journal metadata
("something logged from foo.service" as opposed to "something logged
from (child process of) cron.service").
> If I wanted to run a service, presumably I could just write a 'manual'
> invocation as a cron or at job? I'm not seeing the big imperative to
> create another new bunch of code to learn and maintain. I expect I'm
> blind.
You can view "running code at a specified time" as having two parts:
choosing the time when to start it, and the general ability to run code
in a specified environment (user, sandboxing, resource limits,
dependencies, etc). Cron does the first, but systemd units do the
second a lot better. If you want to have support for both, you either
need to add most of the stuff in systemd units to cron, or timer units
to systemd. The second is a much saner option.
Basically, you want to have support for everything in unit files also
for code that is started based on time. This means that having cron
directly running code is not a real option. And having cron running
"systemctl start" commands is kludgey and has enough problems to
justify native timer units.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] ConditionPathExists vs mount unit
Hi, I have to use the same OS image tarball (created by Yocto) on several machines with different specifications. Where they differ is the disk size and partitioning. On the smaller machine (a Sicom SL20 POS hardware, boots from CF card) the disk size is too small to have separate partitions for certain purposes that are on the other hand mandatory on the larger system. The shipped disks are mass-produced and are pre-formatted with the same UUIDs across all devices so they are interchangeable. So, I discovered the mount unit type: https://www.freedesktop.org/software/systemd/man/systemd.mount.html This page says that the usual [Unit] section options are applicable. I was hoping that the missing partitions can be skipped using the ConditionPathExists= option but it seems it's not the case. On mount unit looks like this: $ cat var.mount [Unit] Description=Variable Data (/var) ConditionPathExists=/dev/disk/by-uuid/e8282db7-dd6d-4231-b2b1-49887648480c ConditionPathIsSymbolicLink=!/var DefaultDependencies=no Conflicts=umount.target Before=local-fs.target umount.target After=swap.target [Mount] What=/dev/disk/by-uuid/e8282db7-dd6d-4231-b2b1-49887648480c Where=/var Options=noatime [Install] WantedBy=local-fs.target This boots properly on the larger system where the extra /var partition exists but the smaller system fails to boot. systemctl status var.mount says: Dependency failed for Variable Data (/var) var.mount: Job var.mount/start failed with result 'dependency' Is there a way to describe optional mounts via such Conditions* options? systemd version is 237. Best regards, Zoltán Böszörményi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] ConditionPathExists vs mount unit
Hi, I have to use the same OS image tarball (created by Yocto) on several machines with different specifications. Where they differ is the disk size and partitioning. On the smaller machine (a Sicom SL20 POS hardware, boots from CF card) the disk size is too small to have separate partitions for certain purposes that are on the other hand mandatory on the larger system. The shipped disks are mass-produced and are pre-formatted with the same UUIDs across all devices so they are interchangeable. So, I discovered the mount unit type: https://www.freedesktop.org/software/systemd/man/systemd.mount.html This page says that the usual [Unit] section options are applicable. I was hoping that the missing partitions can be skipped using the ConditionPathExists= option but it seems it's not the case. On mount unit looks like this: $ cat var.mount [Unit] Description=Variable Data (/var) ConditionPathExists=/dev/disk/by-uuid/e8282db7-dd6d-4231-b2b1-49887648480c ConditionPathIsSymbolicLink=!/var DefaultDependencies=no Conflicts=umount.target Before=local-fs.target umount.target After=swap.target [Mount] What=/dev/disk/by-uuid/e8282db7-dd6d-4231-b2b1-49887648480c Where=/var Options=noatime [Install] WantedBy=local-fs.target This boots properly on the larger system where the extra /var partition exists but the smaller system fails to boot. systemctl status var.mount says: Dependency failed for Variable Data (/var) var.mount: Job var.mount/start failed with result 'dependency' Is there a way to describe optional mounts via such Conditions* options? systemd version is 237. Best regards, Zoltán Böszörményi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ConditionPathExists vs mount unit
2020. 08. 10. 20:08 keltezéssel, Lennart Poettering írta: On Mo, 10.08.20 19:46, Böszörményi Zoltán (zbos...@pr.hu) wrote: Is there a way to describe optional mounts via such Conditions* options? No. .mount units automatically gain dependencies on the devices they are mounted from. Only after all dependencies are fulfilled (i.e. the backing device showed up) the mount is executed, and as first step of that the conditions are checked, i.e. much too late for your case. My recommendation to you: write a generator, see systemd.generator(7) for details. The existing systemd-gpt-auto-generator(8) does pretty much what you want to do already, maybe use that as inspiration. It only supports GPT disk images however, and it auto-detects /var/ partitions only since v245. Generators run very very early at boot and generate units and dependencies. this is where you should genreate your var.mount depending on the partition table. But note you have to implement that very carefuly, and do raw disk accesses, since udev and such is not running that early, nor do you even have the guarantee the kernel itself noticed your extra partition or not yet. The only guarantee you get is that the root partition was already found, everything else might happen concurrently. Thanks, I will look into it. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No signal sent to stop service
Hello Lennart and Michal, Thank you for your replies. The cgroup file is below - can you please advise what is the relevant part to check? The problem is most likely with systemd thinking the program is stopped because "systemctl status" reports: Aug 10 03:57:32 myhost systemd[1]: product_routed.service: Main process exited, code=exited, status=1/FAILURE Aug 10 03:57:32 myhost systemd[1]: product_routed.service: Failed with result 'exit-code'. We will look into that, thank you. # cat /proc/17824/cgroup 12:memory:/ 11:pids:/user.slice/user-0.slice/session-623.scope 10:rdma:/ 9:hugetlb:/ 8:blkio:/ 7:devices:/user.slice 6:cpuset:/ 5:net_cls,net_prio:/ 4:freezer:/ 3:perf_event:/ 2:cpu,cpuacct:/user.slice/user-0.slice/session-623.scope 1:name=systemd:/user.slice/user-0.slice/session-623.scope 0::/user.slice/user-0.slice/session-623.scope On Tue, 11 Aug 2020 at 03:08, Lennart Poettering wrote: > On Do, 06.08.20 13:59, David Cunningham (dcunning...@voisonics.com) wrote: > > > Hello, > > > > I'm developing a service called product_routed which is managed by > systemd. > > The service can normally be stopped with "service product_routed stop" or > > "systemctl stop product_routed", however for some reason after the > service > > has been running for a while (a few days or more) the stop command no > > longer works. Can anyone help me find why? > > > > When the application stop works initially (for the first day or two) we > see > > a TERM signal sent to the application, as confirmed by logging in the > > application itself (which is written in perl), and is reported by "strace > > -p -e 'trace=!all'". However once the problem starts no signal is > > sent to the application at all when "service product_routed stop" or > > "systemctl stop product_routed" is run. > > Note that on systemd for a unit that is already stopped issuing > another "systemctl stop" is a NOP and doesnt result in another SIGTERM > to be sent > > So, when you issue your second "systemctl stop", is the service > actually running in systemd's eyes? (i.e. what does "systemctl status" > say about the service?) > > > The systemd file is as below, and we've confirmed that the PIDFile > contains > > the correct PID when the stop is attempted. Would anyone have any > > suggestions on how to debug this? Thank you in advance. > > > > # cat /etc/systemd/system/product_routed.service > > [Unit] > > Description=Product routing daemon > > After=syslog.target network.target mysql.service > > > > [Service] > > Type=forking > > ExecStart=/opt/product/current/bin/routed > > PIDFile=/var/run/product/routed.pid > > Restart=on-abnormal > > RestartSec=1 > > LimitSTACK=infinity > > LimitNOFILE=65535 > > LimitNPROC=65535 > > > > [Install] > > WantedBy=multi-user.target > > Please provide the "sytemctl status" output when this happens. > > Lennart > > -- > Lennart Poettering, Berlin > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ConditionPathExists vs mount unit
10.08.2020 20:59, Böszörményi Zoltán пишет: > Hi, > > I have to use the same OS image tarball (created by Yocto) > on several machines with different specifications. > > Where they differ is the disk size and partitioning. On the smaller > machine (a Sicom SL20 POS hardware, boots from CF card) the disk size > is too small to have separate partitions for certain purposes that are > on the other hand mandatory on the larger system. > > The shipped disks are mass-produced and are pre-formatted with > the same UUIDs across all devices so they are interchangeable. > > So, I discovered the mount unit type: > https://www.freedesktop.org/software/systemd/man/systemd.mount.html > > This page says that the usual [Unit] section options are applicable. > > I was hoping that the missing partitions can be skipped using the > ConditionPathExists= option but it seems it's not the case. > > On mount unit looks like this: > > $ cat var.mount > [Unit] > Description=Variable Data (/var) > ConditionPathExists=/dev/disk/by-uuid/e8282db7-dd6d-4231-b2b1-49887648480c > ConditionPathIsSymbolicLink=!/var > DefaultDependencies=no > Conflicts=umount.target > Before=local-fs.target umount.target > After=swap.target > > [Mount] > What=/dev/disk/by-uuid/e8282db7-dd6d-4231-b2b1-49887648480c > Where=/var > Options=noatime > > [Install] > WantedBy=local-fs.target > > > This boots properly on the larger system where the extra /var > partition exists but the smaller system fails to boot. > > systemctl status var.mount says: > > Dependency failed for Variable Data (/var) > var.mount: Job var.mount/start failed with result 'dependency' > > Is there a way to describe optional mounts via such Conditions* options? > No the way you are doing it. Device dependency is checked before Conditions* directives are even looked at. If your concern is only boot time, you should consider generators that will create correct mount units for currently present hardware. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit timer
On Mo, 10.08.20 20:19, Dave Howorth (syst...@howorth.org.uk) wrote: > > It kinda makes sense to invoke cronjobs the same way as any other > > piece of system code in userspace: as a service, so that you can take > > benefit of deps management, priv handling, logging, sandboxing and so > > on, so that you can run stuff either manually or by timers or by any > > other kind of activation, and so on, and it always ends up in exactly > > one instance. And there's tons of other stuff too. > > > > i.e. it unifies how system programs are invoked, and that's a good > > thing. it turns time-based activation into "just another type of > > activation". > > Most of that has gone over my head so some examples would probably help > me to understand. Perhaps they're in the git logs? > > But I'm not normally running system code in cronjobs. I usually run > either scripts I have written myself, or backup commands and the > like. Well, by "system code" in this context I mean code running in system code, i.e. not associated with a specific "human" user. i.e. all code traditionally run from /etc/crontab and related dirs is in "system context". > If I wanted to run a service, presumably I could just write a 'manual' > invocation as a cron or at job? I'm not seeing the big imperative to > create another new bunch of code to learn and maintain. I expect I'm > blind. I mean, you don't have to use systemd timers+services, that's entirely up to you. cron continues to work after all. However, there's a ton of stuff in it for you if you do bother running stuff as timer. For example, let's say you wrote your own backup script, that streams your whole OS backup to some server. Stuff like that you want resource manage a bit, i.e. use CPUShares=100 or so to make sure it doesn't take as much resources. You want to lock it down, since it's interacting with the netwokr, and it's bad enough it needs to be able to read all your files, but it sure as hell shouldn't also be able to change them, so you could lock it down with ProtectSystem= and so on. And sometimes you want to start a backup manually, outside of your usual schedule, so there's "systemctl start" of the backup script to do so in a way that won't conflict if the schedule hits while the backup is still running. Then, maybe you need some service to be up while you are doing your backup (or a mount), and it might be used by something else too, but should go away when not used. You can pull it in cleanly from your timer's service now, and mark it StopWhenUnneeded= so that it goes away when no service uses it. And so on and so on. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
