Re: [systemd-devel] early mounts in systemd
On Sat, 1 May 2021 18:08:55 +0200 Michael Biebl wrote: > Am Sa., 1. Mai 2021 um 18:07 Uhr schrieb Michael Biebl > : > > > > Am Sa., 1. Mai 2021 um 17:46 Uhr schrieb Dave Howorth > > : > > > If systemd removes (i.e. doesn't obey) a directive, I'd expect it > > > to be polite and log that fact somewhere. No? > > > > It should, yes. > > To be precise, it should log a message like here > https://sources.debian.org/src/systemd/247.3-5/src/core/transaction.c/?hl=414#L414 Many thanks :) Rick and/or Luca should be able to find that if it is the source of their problems! PS however you sent your mail, it meant that my MUA didn't automatically send a copy to the list when I hit reply. I'd much prefer to keep everything on list. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] early mounts in systemd
Am Sa., 1. Mai 2021 um 18:07 Uhr schrieb Michael Biebl : > > Am Sa., 1. Mai 2021 um 17:46 Uhr schrieb Dave Howorth > : > > If systemd removes (i.e. doesn't obey) a directive, I'd expect it to be > > polite and log that fact somewhere. No? > > It should, yes. To be precise, it should log a message like here https://sources.debian.org/src/systemd/247.3-5/src/core/transaction.c/?hl=414#L414 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] early mounts in systemd
Am Sa., 1. Mai 2021 um 17:46 Uhr schrieb Dave Howorth : > If systemd removes (i.e. doesn't obey) a directive, I'd expect it to be > polite and log that fact somewhere. No? It should, yes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] early mounts in systemd
On Fri, 30 Apr 2021 22:08:17 +0200 Michael Biebl wrote: > Am Fr., 30. Apr. 2021 um 20:27 Uhr schrieb Rick Winscot > : > > > At this point, flush is attempting to re-route /run/log/journal > > to /var/log/journal ... and the /var partition is not yet mounted. > > Units generated for fstab in /run/systemd/generator that manage the > > mount have an After=local-fs-pre.target which is too late. > > > > Other dependency errors appear in the log; all with the same root > > cause. By the time [ a specified service ] that uses /var is ready, > > the partition has not yet been mounted. My solution resolves > > the /var mount as soon as the block device is seen by udev - which > > made all the dependency errors go away. > > Fwiw, I can't reproduce the problem. systemd-journal-flush.service is > correctly started after /var has been mounted. > In case you are interested, I attached a journalctl dump, /etc/fstab > and systemd-analyze dump as well. > As you can see, systemd-journal-flush.service has a proper > After=var.mount ordering. > > I wonder if you have a dependency loop somewhere and systemd resolves > this by removing that ordering. If systemd removes (i.e. doesn't obey) a directive, I'd expect it to be polite and log that fact somewhere. No? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] permanent autologin
Am Samstag, dem 01.05.2021 um 07:17 +0200 schrieb Emanuel Berg: > I do autologin like this: > > ExecStart=-/sbin/agetty -a incal --noclear %I $TERM > > /etc/systemd/system/getty.target.wants/getty@tty1.service # line ~39 > > $ sudo systemctl daemon-reload > > However, it seems to disappear after a while, maybe when > systemd gets updated? > > So my question is how do I make the autologin > change permanent? > Hi Emanuel, your path is wrong. You want the following: --- /etc/systemd/system/getty@tty1.service.d/10-autologin.conf [Service] ExecStart= ExecStart=-/sbin/agetty -a incal --noclear %I $TERM --- This creates a single overwrite for only this one instanciated unit. The first empty ExecStart= is for technical reasons. Do you need this auto login for debug reasons (than maybe debug- shell.service is better suited), do you want to start a terminal 1application (than maybe use a normal .service with TTYPath), or do you start graphical applications (use a login manager with auto login instead)? BR Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] early mounts in systemd
Am Sa., 1. Mai 2021 um 08:44 Uhr schrieb Luca Boccassi : > > On Fri, 30 Apr 2021 at 22:15, Michael Biebl wrote: > > > > I wonder if you have a dependency loop somewhere and systemd resolves > > this by removing that ordering. > > As mentioned earlier, I strongly suspect systemd-tmpfiles-setup.service - I > had the same issue, because my /var/log partition is also not mounted in the > initramfs for $reasons, so it appears late at boot. > I'd suggest again to try and override it. I guess my point is, that before trying to suggest solutions, we should understand what the underlying problem is first. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] permanent autologin
I do autologin like this: ExecStart=-/sbin/agetty -a incal --noclear %I $TERM /etc/systemd/system/getty.target.wants/getty@tty1.service # line ~39 $ sudo systemctl daemon-reload However, it seems to disappear after a while, maybe when systemd gets updated? So my question is how do I make the autologin change permanent? -- underground experts united https://dataswamp.org/~incal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] early mounts in systemd
On Fri, 30 Apr 2021 at 22:15, Michael Biebl wrote: > > Am Fr., 30. Apr. 2021 um 20:27 Uhr schrieb Rick Winscot > : > > > At this point, flush is attempting to re-route /run/log/journal to /var/log/journal ... and the /var partition is not yet mounted. Units generated for fstab in /run/systemd/generator that manage the mount have an After=local-fs-pre.target which is too late. > > > > Other dependency errors appear in the log; all with the same root cause. By the time [ a specified service ] that uses /var is ready, the partition has not yet been mounted. My solution resolves the /var mount as soon as the block device is seen by udev - which made all the dependency errors go away. > > Fwiw, I can't reproduce the problem. systemd-journal-flush.service is > correctly started after /var has been mounted. > In case you are interested, I attached a journalctl dump, /etc/fstab > and systemd-analyze dump as well. > As you can see, systemd-journal-flush.service has a proper > After=var.mount ordering. > > I wonder if you have a dependency loop somewhere and systemd resolves > this by removing that ordering. As mentioned earlier, I strongly suspect systemd-tmpfiles-setup.service - I had the same issue, because my /var/log partition is also not mounted in the initramfs for $reasons, so it appears late at boot. I'd suggest again to try and override it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
