Re: [systemd-devel] Bouncing interface once chrony is synced
On Wed, Jul 05, 2017 at 10:29:21AM -0500, Ian Pilcher wrote:
> I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
> firewall/gateway. The Banana Pi does not have a persistent clock, so
> it has no idea what the time is until it is able to sync via NTP. Thus,
> the initial DHCP leases that the BPi receives have incorrect expiration/
> renewal times (since the system can't sync via NTP before it has an IP
> address - chicken and egg).
Can't you just store the time on shutdown and restore it at boot (e.g.,
take the time of the journal file) - that is usually close enough, at
least it works well enough for use cases in openwrt and lede.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ordering (apt) timer services to not run at the same time
On Thu, Apr 27, 2017 at 11:30:35PM +0200, Julian Andres Klode wrote:
> Hi systemd folks,
>
> (service and timer files being discussed at the bottom)
>
> we are currently reworking the way automatic updates and upgrades work
> on Ubuntu and Debian systems. We basically have two persistent timers
> with associated services:
>
> 1. apt-daily - Downloads new lists and packages
> 2. apt-daily-upgrade - Performs upgrades
>
> The first job should run spread out through the day (we run it twice
> due to some other reasons), the latter in the morning between 6 and 7,
> and at boot, daily-upgrade should be resumed after daily (so we added
> After ordering relations to apt-daily-upgrade timer and service).
>
> Now, we seem to be missing one bit: If daily-upgrade is already
> running, and daily is about to start, daily should wait for
> daily-upgrade to finish. I had hoped that maybe that works
> automatically given that there is some ordering relation between the
> two, but that did not work out. I tried adding Conflicts, but systemd
> then said "loop to fast" and became unresponsive (not sure if caused
> by this, but maybe).
Now it did not loop to fast, so I came to the following observation: We
basically need something like Conflicts that does not kill the already
running (oneshot) service, but simply waits for it to end on its own.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Ordering (apt) timer services to not run at the same time
Hi systemd folks, (service and timer files being discussed at the bottom) we are currently reworking the way automatic updates and upgrades work on Ubuntu and Debian systems. We basically have two persistent timers with associated services: 1. apt-daily - Downloads new lists and packages 2. apt-daily-upgrade - Performs upgrades The first job should run spread out through the day (we run it twice due to some other reasons), the latter in the morning between 6 and 7, and at boot, daily-upgrade should be resumed after daily (so we added After ordering relations to apt-daily-upgrade timer and service). Now, we seem to be missing one bit: If daily-upgrade is already running, and daily is about to start, daily should wait for daily-upgrade to finish. I had hoped that maybe that works automatically given that there is some ordering relation between the two, but that did not work out. I tried adding Conflicts, but systemd then said "loop to fast" and became unresponsive (not sure if caused by this, but maybe). Is there a way to make this work in systemd, or do we need to add locking to the script invocation (like s#ExecStart=#ExecStart=/usr/bin/flock /path/to/lock#)? Here are the services and timers. Any help would be appreciated. ==> apt-daily.service <== [Unit] Description=Daily apt download activities Documentation=man:apt(8) ConditionACPower=true [Service] Type=oneshot ExecStart=/usr/lib/apt/apt.systemd.daily update ==> apt-daily.timer <== [Unit] Description=Daily apt download activities After=network-online.target Wants=network-online.target [Timer] OnCalendar=*-*-* 6,18:00 RandomizedDelaySec=12h Persistent=true [Install] WantedBy=timers.target ==> apt-daily-upgrade.service <== [Unit] Description=Daily apt upgrade and clean activities Documentation=man:apt(8) ConditionACPower=true After=apt-daily.service [Service] Type=oneshot ExecStart=/usr/lib/apt/apt.systemd.daily install ==> apt-daily-upgrade.timer <== [Unit] Description=Daily apt upgrade and clean activities After=apt-daily.timer [Timer] OnCalendar=*-*-* 6:00 RandomizedDelaySec=60m Persistent=true [Install] WantedBy=timers.target -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ordering (apt) timer services to not run at the same time
On Fri, Apr 28, 2017 at 08:46:45AM +0200, Michal Sekletar wrote:
> On Thu, Apr 27, 2017 at 11:30 PM, Julian Andres Klode <j...@debian.org> wrote:
>
> > Now, we seem to be missing one bit: If daily-upgrade is already
> > running, and daily is about to start, daily should wait for
> > daily-upgrade to finish. I had hoped that maybe that works
> > automatically given that there is some ordering relation between the
> > two, but that did not work out. I tried adding Conflicts, but systemd
> > then said "loop to fast" and became unresponsive (not sure if caused
> > by this, but maybe).
>
> After/Before dependencies ensure ordering between respective jobs in a
> transaction (actually between both jobs in a single transaction and
> between jobs that are already in run queue). However, ordering doesn't
> affect jobs that we've already dispatched, since they are already
> running we can't do much about them.
From my testing, if B has After=A, and A is already started, the
startup of B is delayed until A has completed - do you mean that
with run queue, or is that merely by accident somehow?
> Indeed, seems like lockfile + condition in other unit is the simplest way out.
How unfortunate.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ordering (apt) timer services to not run at the same time
On Sat, Apr 29, 2017 at 11:40:44AM +0200, Lennart Poettering wrote:
> That said, there are limits to this: this will only work correctly if
> the start jobs for both units are either enqueued at the same time or
> in the order they are supposed to be run in. If however, the job for
> the unit that is supposed to be run second is enqueued first, it will
> be immediately dispatched (as at that moment ordering deps won't have
> any effect as the other unit isn't enqueue), and if the job for the
> first unit is then enqueued then both will run at the same time. This
> is simply as the queue dispatching order only matters at the moment a
> service is actually triggered, afterwards it doesn't matter anymore.
[...]
> So, I am not sure what i can recommend you, systemd's dependency
> currently cannot express what you want to do, but I sympathize with
> the problem. I am not entirely sure what a good and natural way would
> be though to extend systemd's logic for what you want to do.
>
> Ideas?
This might sound crazy, but I think it might be sense to do one
of this:
(1) just wait regardless of the direction of the ordering relationship
- AKA: if the ordering is "broken" when queuing, reverse the order. Could
be a flag (NeverRunAtSameTime=yes).
(2) A weak ordering type like AfterIfActive=active.service
I'm not sure how this all works out with non-oneshot services,
but that's basically the optimal thing to do here.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Store journal logs to different journals(location) based on Filters
On Wed, Sep 20, 2017 at 06:13:40AM +, P.R.Dinesh wrote:
> Is it possible to store journal logs matching specific filters to different
> journal files in addition to the main journal using some journald
> configurations?
>
>
> For eg., All journal logs of severity critical and above should be stored
> in /var/log/critical/critial.journal in addition to the main journal.
Why? I mean the point of journal is that you can do this querying later
on via journalctl, so there's no point in storing them in different
files - just specify the priority you are interested in to journalctl
instead.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User configs, BTRFS subvolume for /home and automatic service start during boot?
On Fri, May 04, 2018 at 07:03:59PM +0200, Lennart Poettering wrote: > On Fr, 04.05.18 18:59, Thorsten Schöning (tschoen...@am-soft.de) wrote: > > > Guten Tag Lennart Poettering, > > am Freitag, 4. Mai 2018 um 18:07 schrieben Sie: > > > > > Hmm, you said /home was a subvolume? That suggests they are on the > > > same fs? Not following here? > > > > I guess "/etc/fstab" is clearer than my explanation: > > > > > # > > > # / was on /dev/sda1 during installation > > > UUID=0841ef72-e9d4-45ca-af22-a403783859c6 / btrfs > > > noatime,nodiratime,subvol=@ 0 1 > > > > > > # /home was on /dev/sda1 during installation > > > UUID=0841ef72-e9d4-45ca-af22-a403783859c6 /home btrfs > > > noatime,nodiratime,subvol=@home 0 2 > > > > So the same BTRFS file system containing two sub volumes. That seems > > to work for user configs, my problem was a wrong "WantedBy". > > Note that btrfs subvolumes are just special directories, hence you can > also do without an explicit entry for the home subvol, and simply > create it below the root subvol. That's not the best advise IMO. Subvolumes inside subvolumes have weird behavior that sometimes bites you very hard. For example: You can't restore an older / snapshot because it won't contain your /home because it's a subvolume of the current /, but not of the snapshot. It's just going to be a pain if you forget that. I had this problem with lxd - it keeps containers in a btrfs subvolume below /, and then I restored / to an older snapshot and all my containers were gone / broken - I had to recreate them, as I only noticed later and already had deleted my broken old "/"; so I switched to a mount for them: /dev/mapper/ubuntu--vg-root /var/snap/lxd/common/lxd/storage-pools/default btrfs defaults,subvol=@lxd 0 2 For Ubuntu, it's worth noting that the @ subvolume that's mounted to / is automatically snapshotted when upgrading distributions; or even on normal upgrades with apt-btrfs-snapshot. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
