Re: [systemd-devel] systemd unit timer
You could create a timer that starts another timer... Le dim. 9 août 2020 à 16:56, Dave Howorth a écrit : > On Sun, 9 Aug 2020 15:54:55 +0300 > Andrei Borzenkov wrote: > > 09.08.2020 13:40, Vini Harimoorthy пишет: > > > In that case, it will run only in Oct,Nov, & Dec. But, I want to > > > run the timer unit weekly after a specific calendar date & time. > > > How to specify if I want to run some task on every 12 hours after > > > Jan'2021 (start from future date & time) > > > > > > > That's not possible using systemd timer as of now. There was similar > > discussion just recently (a week or two ago). > > Is there anywhere that explains the rationale for systemd timers? > > What's their USP? Why was it necessary to invent the facility? > ___ > 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] [EXT] Re: Q: daemon-reload: when and how?
Le jeu. 18 juin 2020 à 12:44, Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> a écrit : > >>> Jérémy ROSEN schrieb am 18.06.2020 um 11:01 in > Nachricht > > <19710_1592470931_5EEB2D93_19710_59_1_CAFvCimXJwvDg0+5W11H0pUh+EHDTGxgbAuAGpG2PL > gjc0i...@mail.gmail.com>: > > Le jeu. 18 juin 2020 à 08:53, Ulrich Windl < > > ulrich.wi...@rz.uni-regensburg.de> a écrit : > > > >> Hi! > >> > >> I have a question: systemd monitors almost everything it seems to me. > So I > >> wonder: > >> Under what conditions is it necessary to issue a daemon-reload, and why > >> can't systemd find out itself that a daemon-reload is required? > >> > > > > There are some cases where systemd can detect the proper time for a > > daemon-reload, and does it implicitely > > systemd also check mtime of configuration files so it can see when a > > daemon-reload should be done. > > Is there something like "systemd suggests daemon-reload" (assuming systemd > detects the situation, but does not issue a reload itself)? > > Not that I know of... > > > > However it is not because a file has been modified that systemd should > > decide to reload by itself. > > multiple unit files need to work together to make a working environment, > > and systemd can't know when all changes are consistent and > > it is safe to reload. So systemd will want an explicit order from the > user. > > I see (see above). > > > > > So if I think a "manual" daemon-reload is required, is it safe to do it > >> from within a unit? > >> > > > > Usually, calling daemon-reload from a unit is a sign of bad design or > > misunderstanding of some tool. What exactly is the problem you are > > trying to solve ? > > > > > >> I have a "generator-like" type of unit that changes the configuration of > >> other units. However, as it seems, systemd ignores such changes until I > use > >> daemon-reload... > >> > > > > Yes. you need an explicit daemon-reload here. > > why can't it be a real generator ? > > AFAIK generators are quite low-level and have some restrictions. My unit is > kind of high-level (e.g. it needs all filesystems mounted). Actually I > started > with a "normal" generator, but several restriction I can't remember right > now > made me change my mind to convert the generator to a "normal" (more or > less) > unit. > > generators are run very early during boot time so if you need external filesystems mounted, that can indeed be a problem. > > > > could you use systemd-run or the equivalent dbus API to do what you are > > trying to do ? > > Good question! ;-) Browsing through the manpage I got the impression that > it's > systemd's version of "batch" IMHO. I'm unsure whether this has any > advantage > for my problem. For dbus I must admit that I have no experience of any kind > with it... > > Well, it has the advantage of not needing a daemon-reload and of getting rid of the need to create a config file altogether... you talk directly to the running instance of systemd (i'm not sure what you mean by "batch" in this context. this is about creating a unit, not some kind of shell-script-like language) > Regards, > Ulrich > > [...] > > -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Q: daemon-reload: when and how?
Le jeu. 18 juin 2020 à 08:53, Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> a écrit : > Hi! > > I have a question: systemd monitors almost everything it seems to me. So I > wonder: > Under what conditions is it necessary to issue a daemon-reload, and why > can't systemd find out itself that a daemon-reload is required? > There are some cases where systemd can detect the proper time for a daemon-reload, and does it implicitely systemd also check mtime of configuration files so it can see when a daemon-reload should be done. However it is not because a file has been modified that systemd should decide to reload by itself. multiple unit files need to work together to make a working environment, and systemd can't know when all changes are consistent and it is safe to reload. So systemd will want an explicit order from the user. So if I think a "manual" daemon-reload is required, is it safe to do it > from within a unit? > Usually, calling daemon-reload from a unit is a sign of bad design or misunderstanding of some tool. What exactly is the problem you are trying to solve ? > I have a "generator-like" type of unit that changes the configuration of > other units. However, as it seems, systemd ignores such changes until I use > daemon-reload... > Yes. you need an explicit daemon-reload here. why can't it be a real generator ? could you use systemd-run or the equivalent dbus API to do what you are trying to do ? > > (systemd-228-157.9.1.x86_64 of SLES12) > Ouch that's old... Hopefully there are not too many missing features I'm used to have in there... Regards Jeremy > > Regards, > Ulrich > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parent slices and resource control
man pages are part of the systemd repository at github so change it where you think it's the most appropriate and submit a pull-request there Thx for the help Le mar. 2 juin 2020 à 17:49, Patrick Dimond a écrit : > On Mon, Jun 01, 2020 at 12:22:03PM +0200, Lennart Poettering wrote: > > Consider this tree: > > > > -.slice > > `- foo.slice > > | `- miau.service > > `- bar.slice > > | `- bar-quux.slice > > | | `- daemon.service > > | | `- otherdaemon.service > > | `- bar-uuu.slice > > | ` rumpel.service > > `- zzz.slice > >`- zzz-yyy.slice > > `- wuff.service > > > > And now you turn on memory accounting in daemon.service. This would > > then propagate up the three, so you get memory accounting on all its > > parents too: bar-quux.slice, bar.slice and -.slice. And you will get > > it turned on forthe units immediately in throse, i.e. also in > > otherdaemon.service, bar-uuu.slice, foo.slice, zzz.slice. However, it > > will not be turned on in: miau.service, rumpel.service, zzz-yyy.slice > > and wuff.service, since those are neither in the path to the root > > slice nor immediately inside any of those slices. > > > > Makes sense? > > > > Lennart > > > > -- > > Lennart Poettering, Berlin > > Yes! The diagram really helped. > > I think including a diagram like that would be helpful for others too. > I'm not sure where it should live or what the process is, but I'd be > happy to put in the work to make that happen. > > Thanks, > Pat > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing
Le jeu. 27 févr. 2020 à 16:30, Andreas Kempe a écrit : > On Thu, Feb 27, 2020 at 10:04:37AM +0100, Jérémy ROSEN wrote: > > It is somewhat comforting knowing that others are seeing similar > issues. :) > > And not to far... you're a customer of ours :P (well... actia in Toulouse is...) > > I did a complete analysis of what's going on, with a patch that improves > > the situation here : https://github.com/systemd/systemd/pull/14135 > > I am not sure how to deal with it in your specific case. > > the simplest approch would be to mount your overlay in a initrd (or in a > > small script shell that is run before systemd and exec systemd as its > last > > step) > > > > I was contemplating whether it could be acceptable having the same > static machine-id file pre-generated for all systems. I'm not 100% sure > what it's used for, TBH; would it be a really bad idea? > As long as two machines with the same machine-id are never in contact you should be fine... Theoretically the machine-id should never cross the network, but you never know what individual apps might do The only place where that could be problematic is the journal : if you mix the logs of multiple machines with the same machine-id, you won't be able to tell them appart and that might have other side-effects I wouldn't know about... > > > My patch wouldn't really help in your case, but maybe you can "cheat" by > > having the underlying /etc/machine-id bein a symlink to the overlay > > directory... that could work. > > > > I had a look at your patch and as you said, it doesn't really solve > our use case. At the moment, we decided to remove the overlay from the > affected parts and simply require a new system image if one wants to > change /etc. > > We were planning on having signed read-only overlays for configuration > in the future so I guess we'll have to investigate this further at a > later date. > > Thank you for taking the time to respond! > Cordially, > Andreas Kempe -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing
I had similar problems with a case of booting with the rootfs read-only and then becoming read-write later... Basically systemd only checks for machine-id very early (before reading any config file) and does not deal well with /etc changing status... I did a complete analysis of what's going on, with a patch that improves the situation here : https://github.com/systemd/systemd/pull/14135 I am not sure how to deal with it in your specific case. the simplest approch would be to mount your overlay in a initrd (or in a small script shell that is run before systemd and exec systemd as its last step) My patch wouldn't really help in your case, but maybe you can "cheat" by having the underlying /etc/machine-id bein a symlink to the overlay directory... that could work. Regards Jeremy Le mer. 26 févr. 2020 à 10:59, Andreas Kempe a écrit : > Hello everyone, > > I'm working in a project with an embedded Linux system based on > Openembedded using Systemd version 241 as our init process. We're > using a read-only /etc. To facilitate development, we want to use a > writeable overlay on /etc, but we ran into an issue. > > When we start, Systemd detects that there is no machine-id file > present in /etc so it generates and mounts a /etc/machine-id. When our > mount unit then applies the overlay on /etc, it hides the mounted > file. Journald later fails to start because /etc/machine-id isn't > visible through the overlay. > > At this point we're considering a number of workarounds, but I thought > it worthwhile asking the experts before we go patching Systemd or > similar. > > My gut feeling is that using overlays on /etc can't be that uncommon > and it is likely PEBKAC on our end. Is there some canonical way of > doing overlays with Systemd and we're screwing things up? > > Thank you in advance for any help! > Cordially, > Andreas Kempe > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] elegant way to use a single mount unit file for multiple paths
You can't use templates with .mount units because .mount units need to be
named exactly after their mount point.
That's probably not explicitly documented, but might be a good idea to add.
For your use-case, I would probably use a generator (man systemd.generator)
to solve that...
It might not solve your problem, since we don't know when exactly do the
mount themselves happen but it would work for the simple, mount at boot,
case
HtH
Jeremy
Le jeu. 23 janv. 2020 à 18:30, Marcel Partap a écrit :
> Salut,
> for our live debian USB stick distro for students (
> https://github.com/fsfw-dresden/usb-live-linux ), we want to minimize on
> flash writes by putting several paths into a tmpfs overlay. So there is a
> pre-overlay@.service with
>
> > [Unit]
> > Description=Prepare writable overlay on %f
> > DefaultDependencies=no
> > RequiresMountsFor=/run
> >
> > [Service]
> > Type=oneshot
> > ExecStart=/bin/mkdir -p '/run%f'
> > ExecStart=/bin/mount -t tmpfs -o noatime tmpfs '/run%f'
> > ExecStart=/bin/mkdir -p '/run%f/work' '/run%f/rw'
>
> and f.e. a var-lib-apt-lists.mount with
> > [Unit]
> > Description=tmpfs overlay of %f
> > Conflicts=umount.target
> > Wants=pre-overlay@%p.service
> > After=pre-overlay@%p.service
> >
> > [Mount]
> > What=overlay
> > Type=overlay
> > Where=%f
> > Options=lowerdir=%f,upperdir=/run%f/rw,workdir=/run%f/work
> >
> > [Install]
> > WantedBy=local-fs.target
>
> Currently, the file is just cloned for multiple paths, which is working
> but not very elegant. I tried changing it into an instanced unit file
> tmpfs-overlay@.mount, which did not work ("Unit type mount cannot be
> templated" in journal only, nothing from systemd-analyze verify or the
> systemd.mount man page).. Neither did calling the file
> tmpfs-overlay.mount.unit and symlinking to it as var-lib-apt-lists.mount,
> var-cache-apt.mount etc.
>
> So what would be a more elegant way to not have multiple copies of the
> very same file?
>
> Best Regards,
> #marcel
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
[image: SMILE] <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
[image: email] jeremy.ro...@smile.fr
[image: phone] +33 6 88 25 87 42
[image: url] http://www.smile.eu
[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>
[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Issue on Ordering of systemd services during boot
You probably have another problem lurking behind... A.service is of Type=Simple. That means that systemd doesn't know when A.service is ready and will lauch B.socket as soon as A has been launched. B being a socket, it has no delay so will be ready instantly. You probably want to change Type to something more suiting to your use-case... Le mar. 10 déc. 2019 à 09:21, Colin Guthrie a écrit : > I presume B.socket is some kind of network socket rather than filesystem > path? Either that or A.service provides the filesystem for the socket path? > > That being the case, you've got an ordering cycle here as B.socket has > WantedBy=sockets.target which is order before multi-user.target which is > needed by A.service. > > Take the WantedBy out of the B.socket (and ensure you remove any > symlinks that were created when it was installed/enabled - better to do > "systemctl disable B.socket" before editing the unit!) and replace it > with multi-user.target too (like A.service) and this should remove the > ordering cycle and give more deterministic behaviour. > > HTHs > > Col > > > TARANA, YASHASHVI wrote on 10/12/2019 07:07: > > Hi, > > > > > > > > I have a systemd service /A.service/ and socket /B.socket /and its > > corresponding service /B./service with the following content: > > > > > > > >/A.service/ > > > > [Unit] > > > > Description=A.service > > > > > > > > [Service] > > > > ExecStart=/root/test start > > > > RemainAfterExit=true > > > > ExecStop=/root/test stop > > > > Type=simple > > > > > > > > [Install] > > > > WantedBy=multi-user.target > > > > > > > >/B.socket/ > > > > [Unit] > > > > Description=B.socket > > > > *After=A.service* > > > > *BindsTo=A.service* > > > > > > > > [Socket] > > > > ListenDatagram= > > > > Accept=No > > > > > > > > [Install] > > > > WantedBy=sockets.target > > > > > > > > > > > >/B.service/ > > > > [Unit] > > > > Description=B.service > > > > Requires=B.socket > > > > > > > > [Service] > > > > Type=simple > > > > ExecStart=/root/test1 > > > > StandardInput=socket > > > > > > > > [Install] > > > > WantedBy=multi-user.target > > > > > > > > > > > > I need /B.socket/ to start only after /A.service/ during boot. However, > > even after setting */After=A.service/*//and */BindsTo=A.service/*//in > > /B.socket/, sometimes /B.socket/ is starting before /A.service/. > > > > > > > > Please let me know if I am missing something. > > > > > > > > > > > > Thanks and Regards, > > > > Yashashvi > > > > > > > > > > _______ > > systemd-devel mailing list > > systemd-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > > > -- > > Colin Guthrie > gmane(at)colin.guthr.ie > http://colin.guthr.ie/ > > Day Job: > Tribalogic Limited http://www.tribalogic.net/ > Open Source: > Mageia Contributor http://www.mageia.org/ > PulseAudio Hacker http://www.pulseaudio.org/ > Trac Hacker http://trac.edgewall.org/ > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user slice changes for uid ranges
I don't have a complete solutions, but here are a couple of tools that you might be able to assemble into something that work * dropins, you could do a dropin for every existing UID that sets the Slice= field * generators : could be used to generate those dropins * also note that if a unit is named a-b-c.service, systemd will look for dropins named a-b-.service and a-.service... there might be something to do with that, but I havn't given it much thought Le ven. 27 sept. 2019 à 18:28, Mantas Mikulėnas a écrit : > On Fri, Sep 27, 2019 at 5:03 PM Stijn De Weirdt > wrote: > >> hi all, >> >> i'm looking for an "easy" way to set resource limits on a group of users. >> >> we are lucky enough that this group of users is within a (although >> large) high enough range, so a range of uids is ok for us. >> >> generating a user-.slice file for every user (or symlink them or >> whatever) looks a bit cumbersome, and probably not really performance >> friendly if the range is in eg 100k (possible) uids. >> >> e.g. if this range was 100k-200k, i was more looking for a way to do >> e.g. user-1X.slice or user-10:20.slice >> > > As far as I know there isn't a good systemd-native method for this, but > you can dynamically set slice parameters during PAM processing, as in this > blog post: > https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu1804SystemdUserLimits > > -- > Mantas Mikulėnas > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "semaphore" for .timer-triggered run
Out of curiosity, and to check if I understand the systemd concepts properly... assuming the two units to lock are both systemd services and are both of type oneshot, would a simple After= of one on the other be enough to guarantee they never run together ? Le mar. 27 août 2019 à 12:56, Lennart Poettering a écrit : > On Fr, 02.08.19 13:24, Johannes Ernst (johannes.er...@gmail.com) wrote: > > > I have a oneshot .service (certbot) that is run by its .timer with: > > > > OnCalendar=daily > > RandomizedDelaySec=1day > > > > I also have a sometimes long-running script that may modify the same > > data. So the script and the oneshot service should never run at the > > same time. > > > > Is there a good systemd pattern for some kind of semaphore-like > > thing that will delay the execution of the oneshot service and try > > again when the script is done running? > > > > I could skip execution, but then I miss an entire day until the > > service is run again -- I’d prefer it if it tried again a few > > minutes later. Or I could poll for some flag before running the main > > part of the service. Wondering whether there something more > > systemd-native. > > Maybe change the service program invoked by the timer unit to use file > locking of some kind early on. I mean, if you have shared data on disk > and want to synchronize access to it then a file lock is the concept > of choice really. If this is a proper program (i.e. not a shell > script) maybe just use a BSD file lock (flock(2)) on the top-level > directory you store your data in. If these are shell scripts you > should be able to use util-linux' flock tool, you could even prefix > your ExecStart= line with that if you want. > > But no, systemd does not provide any mechanism to do file locking for > you. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deferring start of service until file exists
I'm not very clear on what you are trying to do, so if my understanding is correct: daemon.service : the service you are trying to delay trigger_file : the file created by dhclient moreover you want daemon.service to be part of the startup transaction (I'm not certain why) and not triggered on the file creation as a .path unit would do. I would create an intermediate service wait_for_file.service that would be Type=oneshot and would simply trigger some sort of shell script waiting for trigger_file to appear and the terminate. daemon.service would have Wants=wait_for_file and After=wait_for_file and you should be good. a .path would be a slightly different way of doing it that would not be limited to the startup phase, but again i'm not completely sure what you are trying to do HTH Jeremy Le lun. 19 août 2019 à 14:49, Colin Hogben a écrit : > Hi, > (Hoping this is an appropriate place to ask this question...) > > During system start-up, I want to defer starting a unit (a service) > until a particular file is written (amongst other dependencies). In > my case I am writing the service's configuration file within a > dhclient hook script. > > Any guidance on achieving this with systemd would be much appreciated. > > I don't think a .path unit is the appropriate tool for the job, since > AIUI that is intended to start a new systemd transaction rather than > for scheduling within an existing transaction. I tried having my > service depend on (via Requires/After) the foo.unit related to > foo.path, but then systemd starts foo.unit straight away regardless of > foo.path. If I have After=foo.unit and Requires=foo.path, then it seems > like foo.unit is not "pulled in", and the After has no effect. But > maybe I missed something. > > The .path causes its related unit to start, whereas I think I want to > provoke a transition in a unit from startING to startED - am I right? > > I thought of using the 'inotify' executable within a unit upon which > my service could depend. Unfortunately, CentOS (& Redhat) in their > wisdom decided not to package inotify-tools. > > Thanks for any help, > -- > Colin Hogben > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] symlinking /etc/hostname to /data/etc/hostname woes
For that kind of complicated case, I would recommand mounting /data in your initrd (i.e before the real systemd is started) If you don't have an initrd in your system, you can replace systemd with a simple shell script. We did something similar recently #!/bin/sh /bin/mount /dev/sda4 /data exec /usrlib/systemd Note that we "exec" systemd, not just call it from the shell script. It is important that the real systemd is run as pid1 Le lun. 1 juil. 2019 à 08:25, Belisko Marek a écrit : > Hi, > > I'm working on rpi3 by using mender OTA system and for identifying > devices I would like to have for every of it different hostname. As > rootfs is update-able (rootA, rootB layout) so I tried to create file > in /data/etc (which is permanent) and in /etc create symlink. When now > boot my system I still get hostname localhost. > > My log is: > > journalctl -b | grep hostname > Jun 28 19:18:14 localhost systemd[1]: No hostname configured. > Jun 28 19:18:14 localhost systemd[1]: Set hostname to . > Jun 28 19:18:16 localhost kernel[137]: [1.507423] systemd[1]: No > hostname configured. > Jun 28 19:18:16 localhost kernel[137]: [1.507454] systemd[1]: Set > hostname to . > Jun 28 19:18:16 localhost systemd-resolved[135]: Defaulting to hostname > 'linux'. > > If I read sources correctly hostname is set in early startup of > systemd and then using systemd-hostnamed (which I've edited and added > Requires=data.mount -> as I need to wait when /data partition is > mounted). > > Also when system is booted and /data is mounted and run below I get > strange issue: > > root@localhost:~# hostnamectl set-hostname 321 > Could not set property: Failed to set static hostname: Read-only file > system > root@localhost:~# Jul 03 17:26:01 321 systemd-hostnamed[336]: Failed > to write static host name: Read-only file system > Jul 03 17:26:01 321 systemd-resolved[135]: System hostname changed to > '321'. > > while / and /data are both rw. > > Any ideas how to overcome this problem? Thanks. > > BR, > > marek > > -- > as simple and primitive as possible > - > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Syslog-ng Failed
Le ven. 7 juin 2019 à 16:18, Reindl Harald a écrit : > > > Am 07.06.19 um 16:14 schrieb Blaise T: > > > > etc/syslog-ng$ systemctl start syslog-ng > > Job for syslog-ng.service failed because the control process exited with > > error code. See "systemctl status syslog-ng.service" and "journalctl > > -xe" for details. > > > > systemd[1]: Failed to start System Logger Daemon. > > systemd[1]: syslog-ng.service failed. > this is not a systemd problem beause the service exits and systemd is > the messenger telling you - cause and effect > > I think it is The message is that the control process exited, not the main process. The control process is purely internal, This means that there is something wrong in your service and that systemd refuses to start it. It stops before even attempting your main command Could you please pastebin the output of the two following commands ? * systemctl status syslog-ng * systemctl cat syslog-ng Thx Jeremy > either "systemctl status syslog-ng.service" has something useful or you > need to report that to syslog-ng or your distribution > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/6] pstore: The new documentation for the pstore configuration file
Is there a pstore related man page you could add to the reference section? Le jeu. 16 mai 2019 à 17:03, systemd github import bot a écrit : > Patchset imported to github. > To create a pull request, one of the main developers has to initiate one > via: > < > https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1558016915-24397-7-git-send-email-eric.devolder%40oracle.com > > > > -- > Generated by https://github.com/haraldh/mail2git > ___ > 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] Antw: Re: Re: "bad" status for genersated target; why?
well, in another thread, it was discussed why generated should never have an install section and why enablement does not make sense for them... so no it's not a bug. Arguably, yes, generators do need to care about symlinks, though, maybe the could call "systemctl add-wants --transient" to do the job, but at that point, that's more pedantic than practical. If you write a generator, your systemd-fu should be high enough to know and understand systemd's symlink mechanisms... Le mer. 15 mai 2019 à 11:25, Andrei Borzenkov a écrit : > On Wed, May 15, 2019 at 12:17 PM Lennart Poettering > wrote: > > > > > > To me it's the most horrible part of systemd: Messing with > > > symlinks... > > > > You should never need to. For all relevant operations there are > > "systemctl" verbs, i.e. "systemctl enable", "systemctl disable", > > "systemctl add-wants" and so on. > > > > So the following is a bug? > > localhost:~ # systemctl enable usr-local.mount > Failed to enable unit: Unit /run/systemd/generator/usr-local.mount is > transient or generated. > localhost:~ # exit > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd service and structured logging
you can have both your app and the wrapper launched by a shell, and have systemd monitor the shell... Le lun. 6 mai 2019 à 09:09, Thomas Güttler a écrit : > Am 03.05.19 um 13:29 schrieb Jérémy ROSEN: > > if you want the whole power of structured logs, you need to use the > journald API > > I am not sure in what language your program is written, but if you are > using C, it's pretty trivial to do > > (and i'm pretty sure most bindings are trivial to use too) > > > Yes, this would work. > > > Solution 1: > My service (written Python) uses the journald API. > Disadvantage: My script can't be run under a different environment > (without journald) > > > > Solution 2: > I let my service write json to stdout and a wrapper collects these lines > and the wrapper uses the journald API. > Disadvantage: Systemd is monitoring the wrapper, not the real service. > Signal handling for stopping and restarting > is not direct from systemd to service. > > > The perfect solution is not found yet. > > Regards, >Thomas Güttler > > > -- > Thomas Guettler http://www.thomas-guettler.de/ > I am looking for feedback: > https://github.com/guettli/programming-guidelines > -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd service and structured logging
if you want the whole power of structured logs, you need to use the
journald API
I am not sure in what language your program is written, but if you are
using C, it's pretty trivial to do
(and i'm pretty sure most bindings are trivial to use too)
Automated parsing of stdout is limited, you can
* add a (constant) key=value to all messge
* automatically parse a "" prefix and transform that into a message
gravity
and that's pabasically it. for anything more complex, you need to go
through the journald API
Le ven. 3 mai 2019 à 11:14, Thomas Güttler a
écrit :
> I have a systemd service which is of type "simple".
>
> I want my service to log key-value pairs.
>
> Is there a way to use structured logs with systemd?
>
> For example my service writes this to stdout:
>
> {"key1": "value1", "key2": 1234}
> {"key1": "value2", "key2": 5678}
> ...
>
>
> It would be great of systemd could read the string as json.
>
> Related question at StackO:
> https://stackoverflow.com/questions/55806921/systemd-service-and-structured-logging
>
> I see two ways:
>
> V1: my logs get stored in journald as message (as plain string).
>
> V2: my key-value pairs get stored in the journald key-value dictionary.
>
> What do you suggest?
>
> Background: I don't want an ELK stack. I want a simple solution. Since
> journald already has key-value pairs for a log entry, why not use it?
>
>
> --
> Thomas Guettler http://www.thomas-guettler.de/
> I am looking for feedback:
> https://github.com/guettli/programming-guidelines
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
[image: SMILE] <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
[image: email] jeremy.ro...@smile.fr
[image: phone] +33 6 88 25 87 42
[image: url] http://www.smile.eu
[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>
[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to schedule a resource consuming service
I had proposed https://github.com/systemd/systemd/pull/7023 as a way to deal with a similar problem. This might help you. The idea is to have a timer trigger 5' after boot and hace the timers you are interested in be started by that timer. This allows to make sure they are not triggered in the 5' after boot that's not exactly what you want (it's after boot, it doesn't deal with hibernation) but it might give you ideas HtH Le lun. 4 févr. 2019 à 13:04, Lennart Poettering a écrit : > On Sa, 02.02.19 14:50, Fabrice Salvaire (fabrice.salva...@orange.fr) > wrote: > > > This is painful when we want to use the machine asap, for a quite full > 500 > > GB disk, it hangs during several minutes. I encountered an unusable > machine > > during more than 10 min due to mlocate and/or gnome indexer saturating IO > > and package cache update saturating a low ADSL connexion. > > > > I noticed IOSchedulingClass=2 could be set to "idle", maybe it would > > improve. > > Setting IOSchedulingClass to 2 is equal to "best-effort", which is > actually the Linux default. > > Setting to "idle" might work, but I am not sure it's really the ideal > approach either, as it means that this service could be starved out > entirely until all eternity if something else wants IO > constantly. Usually it's better and sufficient to just set the Nice= > level to something really high, as that propagates to both the CPU and > IO schedulers, and means that everything else will be scheduled > preferably, but your service will still get a bit of CPU/IO time every > now and then so that it doesn't starve to death. (that said, playing > around with "idle" might definitely be worth the excercise) > > Quite frankly, if Nice=19 is not sufficient for your usecase, and this > still affects behaviour of your system too badly, then this indicates > that the IO scheduler on selected on your system isn't any good or the > hw really limited? > > If nicing some IO heavy job to 19 still affects everything else so > badly, then ultimately I figure this becomes a question for the kernel > IO folks. systemd after all can only tell the kernel at what priority > to schedule something, how things are actually scheduled is done by > the kernel itself. > > > I also read > > https://www.freedesktop.org/software/systemd/man/systemd.timer.html but > I > > don't understand if there is a way to prevent to run the service during > 1h > > after boot. > > There's currently no concept of defining "negative" timers, i.e. to > first say "run this so and so often", but then say "but not at these > times". It might be worth adding that, but this would require a bit of > work, and I am not sure how the syntax could look like... > > > Well a way to run theses services during idle time. > > We have no concept for that. The assumption so far that the Linux IO > scheduler is good enough so that we don't have to second guess it, and > it knows on its own when it's a good time to schedule a process as > long as we tell it a useful priority... > > Lennart > > -- > Lennart Poettering, Red Hat > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-analyze time not giving kernal bootup time.
What version of systemd are you using ? Kernel time is usually not displayed when systemd is run inside a container (since it makes no sense). There might be something wrong with container detection here, though... Le lun. 28 janv. 2019 à 10:22, deepan muthusamy a écrit : > My target(RCAR-H3) runs with yocto project have boot up time of 13 seconds > before init starts as of my observation. because I am starting Weston in > basic.target which is starting after 13 seconds from the time I pressed > power button. > > Note: I am booting the board from SD card(The image is in SD card). > > "Systemd-analyze time " giving "Startup finished in 11.814s(userspace) = > 13.519s". > It is not giving kernal bootup time. > Help me with this. > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- [image: SMILE] <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique [image: email] jeremy.ro...@smile.fr [image: phone] +33 6 88 25 87 42 [image: url] http://www.smile.eu [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook] <https://www.facebook.com/smileopensource> [image: LinkedIn] <https://www.linkedin.com/company/smile> [image: Github] <https://github.com/Smile-SA> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu] <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
yes... adding a "this is the start of the freeze" tag sounds like a low
hanging fruit... it's almost no work for the core team to do, and it would
be a clear signal that the freeze period is starting...
Le mer. 16 janv. 2019 à 01:14, Christian Hesse a écrit :
> Lennart Poettering on Tue, 2019/01/15 20:00:
> > Note that we don't branch releases right now. Instead when we are
> > getting closer to a release we simply don't merge PRs we don't
> > consider appropriate for the release anymore until after the
> > release. Or in other words: the master branch simply "stops" for a
> > while getting new stuff, and only gets bugfixes until we release the
> > version, which reopens the floodgates
>
> Most people do not notice when this happens. Having milestones on github is
> nice, but most of us miss that. Just make it obvious: add a tag when
> you start preparation for a release - no matter if you call it
> 'v241-freeze',
> 'v241-rc' or whatever. I guess 'communication' on the lowest level can
> help a
> lot here.
>
> (BTW, there's another place I would like to see more tags... Would be nice
> to
> have signed tags whenever a bunch of commits lands in a stable branch.)
> --
> main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
> "CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
> putchar(b-1/(/*Chriscc -ox -xc - && ./x
> */b/42*2-3)*42);}
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
[image: SMILE] <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
[image: email] jeremy.ro...@smile.fr
[image: phone] +33 6 88 25 87 42
[image: url] http://www.smile.eu
[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>
[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature_medium=email_campaign=signature>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
Make of that what you will. I was expecting a.service to stop because b.service failed, but apparently my understanding of this isn't quite right. And that's kinda my point... most people (me included until recently) expect that behaviour I think the overall conclusion of that conversation is that... everything is very confusing and everybody is very confused. I'll try to clarify the docs and create a PR for that... It seems to be severely needed. -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
So... Requires = Wants + PartOf Requires + After = Wants + PartOf + Requisite + After better ? My goal is to try to clarify that in the documentation at some point... I don't think Requisite= comes into it at all. Requisite= propagates a "start" or "restart" job as a "verify-active" job. In other words, it only checks that the other unit is active, failing the activation of the current unit if necessary. Requires= propagates these as "start" jobs, activating the other unit if it is not already active. I'm pretty sure that there is something about Requires making a unit fail if it's dependency has already failed when it is scheduled for startup... Again I may be wrong... -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
On 02/01/2019 10:08, Michael Chapman wrote: Requires = Wants + Requisite + PartOf is that correct ? I think it's just: Requires = Wants + PartOf Wants= propagates "start" and "restart" jobs as "start" jobs on the other unit. ConsistsOf= (the inverse of PartOf=) propagates "stop" and "restart" jobs as "stop" and "try-restart" jobs respectively on the other unit. So Wants= configures activation dependencies in one direction, and PartOf= configures deactivation dependencies in the other direction. (I'm taking this from transaction_add_job_and_dependencies in src/core/transaction.c, if anybody wants to check my working.) So... Requires = Wants + PartOf Requires + After = Wants + PartOf + Requisite + After better ? My goal is to try to clarify that in the documentation at some point... -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
On 02/01/2019 09:59, Olaf van der Spek wrote:
On Wed, Jan 2, 2019 at 9:54 AM Jérémy Rosen wrote:
i.e if A Requires B, you would expect failures of B to prevent A from starting.
* This is not the case if B is (randomly) scheduled after A.
* This is the case if B is (randomly) scheduled before A.
This is the race the implicit After= would prevent.
There is no such race as Requires without After doesn't stop A from
starting (as it can't).
>From the docs:
If one of the other units fails to activate, and an ordering
dependency After= on the failing unit is set, this unit will not be
started.
you sure about that ? I mean... that's what the doc says, but that
would mean that requires without after is like Wants+PartOf
that's kinda weird. maybe it's an aritifact from early systemd, but
it sounds kinda inconsistent...
Also it means that if you start A, this will start B
if B fails, A is still started ? I don't think a failure of B schedules
a shutdown of A
This whole thing is very confusing...
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .service and .socket
On 02/01/2019 07:31, Michael Chapman wrote: On Tue, 1 Jan 2019, Olaf van der Spek wrote: Hi, AFAIK socket units require a separate file, which seems more complex then it has to be. 1. Could sockets be specified directly in the .service file? If anything, I should think it would work the other way around: a .socket without any activatable .service is relatively useless. But I'm not proposing that this actually be implemented. A socket can trigger a service with a different name using Service= moreover a service can be triggered by multiple sockets. It's a bit complicated to use (check Socket= in [Service]) but it can be handy if you want your web server to be started both by 80 and 8080 2. If not, could the .service file gain a default / implicit dependency on the .socket file? There are a some reasons for not having a .service dependent upon its .socket. Many services can be started directly and will work correctly even when not passed any sockets from systemd. 3. AFAIK Install.WantedBy doesn't have a default. Could it get a proper default? WantedBy is valid for all units, not just services and can have lots of proper values, not just default.target. Lots of on demand daemons do not have a WantedBy at all. they have Also= That doesn't make much sense. Take your example: xhp.service: [Unit] Requires=xhp.socket [Install] WantedBy=default.target xhp.socket: [Socket] ListenStream=/run/xhp.socket This would start xhp.service at daemon startup (i.e. boot, for the system daemon) whether or not the service is actually required. One of the reasons for using socket activation is to _not_ start services when they're not required. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
In my opinion, I don't think the extra inconsistency we get from this is worth it. It literally only saves one line in a unit file. It's not about saving a line in the unit file, it's about avoiding errors on the most common case i.e if A Requires B, you would expect failures of B to prevent A from starting. * This is not the case if B is (randomly) scheduled after A. * This is the case if B is (randomly) scheduled before A. This is the race the implicit After= would prevent. That being said... the fact that Requires influences both startup and restart/shutdown makes things a bit more complicated... From reading the documentation it seems that Requires without After is equivalent to PartOf and thus is suspicious (if you want PartOf, you should use PartOf, if you want Requires, the you should also use After) This means that there are cases to be checked for but I still globally think that Requires without After is suspicious, and that an implicit order would make sense... but that's just my opinion and I am still a bit confused about the fine-details of what Requires does. my understanding is Requires = Wants + Requisite + PartOf is that correct ? Regards Jérémy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
What's the benefit of not having After= for those services? I guess they can start and do their initialization in parallel with the service they require. In that case, what is the benefit or Requires vs Wants ? I might be missing something about what Requires does (shutdown ?) but at that point, Wants would be a better dependency, no ? -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
The short answer is that Requires without after makes little sense, since you can't reliably know if your dependency is here without it (if it fails at startup, you might or might not be started, depending on the startup order systemd chooses) however, for backward compatibility reasons, those two will most likely stay separate. I think a bigger warning in the docs that those two should usually be used together would be welcomed. Cheers Jeremy On 30/12/2018 12:05, Olaf van der Spek wrote: Hi, Evverx suggested I ask here @ https://github.com/systemd/systemd/issues/11284 It's about Requires and After. I think a unit in Requires should imply that unit in After too, otherwise the requirement isn't really met. Is there a use case for Requires but not After? If not, would it make sense to change semantics to have Requires imply After? Requires and After are a common source of confusion: https://serverfault.com/questions/812584/in-systemd-whats-the-difference-between-after-and-requires https://unix.stackexchange.com/questions/388586/systemd-requires-vs-wants -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Secondary mounts
I'm not entirely sure what you are trying to do, so my answer might not be correct * Create mount units for your subfolders * add a WantedBy line to the main mount unit in those subunits if I understand your problem correctly, that should do the trick... On 13/12/2018 23:15, Kenneth Porter wrote: How could I trigger mounting of additional filesystems from the mounting of a CIFS share? The additional mounts would be to subfolders within the primary mount. I'd use symlinks but I get a "this filesystem doesn't support that operation" when I attempt a "ln -s". The primary is automounted via an .automount unit, if that makes a difference. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: static fallback ip for DHCP
For embedded systems, I would recommand connman over networkd exactly
for that sort of reasons.
networkd has been designed mainly for the datacenter use-cases with lots
of interfaces appearing and disapearing dynamically (dynamic containers)
for the embedded case where we have only a few network interfaces but
the network itself changes a lot, connman might be a better choice.
On 22/11/2018 08:21, Benjamin Wozniak wrote:
Hi,
we are developing an embedded device that can only be accessed via network.
If DHCP is used for network configuration we need a plan B if for some reason
no lease can be obtained. Our idea is to have a static IP as fallback.
In systemd I didn't find any hooks to react to a lease fail. The files in
/var/run/systemd/netif apparently should not be used ("# This is private data.
Do not parse.").
Is the idea of a fallback IP address just not a good one, is such functionality
just not implemented in networkd or am I missing something here?
Thanks in advance,
Benjamin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd blocks update kernel partition table
systemd creates .device for any partition it finds, but that doesn't mean the partition is mounted. You should trust "mount" in this case. Your partition is not mounted and I don't think this is a systemd problem. People on the yocto side are probably more able to help now, that being said, I am not sure what "the kernel partition table" is in this context. I assume parted is trying to refresh the way the kernel sees the partitions on the eMMC and fails, which would be a pure kernel problem. If you repartition your eMMC and then reboot on the sd-card, does your kernel see the partitions correctly ? It kinda seems to me that everything is working fine here, and that the message is a red herring... On 21/11/2018 23:38, e-...@gmx.de wrote: Sorry for my html mail before! Hi list, i'm new to systemd and are working with an embedded device with yocto. In my embedded device i want to format and store my emmc device with the new firmware. When updating the firmware the device boots from SD card. When updating the firmware i want to (re)partition my emmc storage device with parted and 3 ext4 partitions. None of the partitions is mounted, because the device boots from SD card. When the emmc already contains a partition table parted complains that it can't update the kernel partition table after it was modified. It seems these partitions are already mounted anywhere. partprobe doesn't help either. But i don't mount them and when i check for mounted partitions by mount command, none of them is mounted. The only thing i see is that systemd has created device units for these partitions. In syslog i see that the ext4 partition is recognized (also in /sys/fs/ext4 available). I assume that the systemd device units block the update of the kernel partition table. I need to modify, format and fill the partitions on the emmc without booting after the new partition table is written. My question is: What/is systemd blocking the update of the kernel partition table and what can i do to prevent it? Thanks in advance Eberhard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Add timer exception
I would have my timer be duration-based instead of calandar based
(assuming that fits your need)
You could use one of the following
OnActiveSec=48h (two days after the timer last triggered
OnUnitActiveSec=48h (two days afte the unit was last started)
Or slightly different
OnUnitInactiveSec=24h (one day after the service FINISHED)
In all those cases, since this is interval based, you would need a way
to "prime the pump" I usually do this with
OnStartupSec=15m (1/4h after the machine was started)
or simply by enabling the service itself so it's part of the boot
sequence (this will work with OnUnitActive and OnUnitInactive, but not
with OnActive)
On 05/11/2018 09:36, Andy Pieters wrote:
Dear Systemd list
I have got a job that I want to execute every other day.
The job is rather lengthy and takes more than 24 hours to complete but
less than 48.
So here are my criteria:
Start today
Start the day after tomorrow (t+2d)*1
Start the (t+2d)*2
Start 2 days after that (t+2d)*n
My timer unit:
[Timer]
OnCalendar=*-*-01,03,05,07,09,11,13,15,17,19,21,23,25,27,29,31 03:30:00
The problem with that is when I simulate the execution dates,
specifically at newyear:
Tue 2018-12-25 03:30:00 CET
Thu 2018-12-27 03:30:00 CET
Sat 2018-12-29 03:30:00 CET
Mon 2018-12-31 03:30:00 CET
Tue 2019-01-01 03:30:00 CET
Thu 2019-01-03 03:30:00 CET
Sat 2019-01-05 03:30:00 CET
Mon 2019-01-07 03:30:00 CET
Wed 2019-01-09 03:30:00 CET
We can see that the timer would be triggered two days in a row.
What can we do about this, please? Is there a better way to define a
timer to run every other day? Can we perhaps add an exception for a
specific date?
Thank you kindly
Keep up the good work!
Andy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Not able to start Weston dependent application
On 31/10/2018 12:40, Pekka Paalanen wrote:
On Wed, 31 Oct 2018 11:32:45 +0100
Jérémy Rosen wrote:
socket-activated weston ?
nice :)
Why does weston require logind ? I work in the embedded world and we
usually disable logind entirely (no users in the "human user" meaning of
the term)
That's when you run Weston as a normal user: logind grants access to
DRM and input devices and revokes access as well when appropriate.
Ok, no problem, we can deal with that in lots of ways.
I was afraid there was some more tricky stuff (dependencies on dbus API
or something like that)
logind is not a hard requirement. That option has usually been
called for by people who don't have systemd at all. I'm not sure Weston
has ever been tested on systemd but without logind. Or maybe it works
and no-one told upstream. :-)
It works and no one told upstream :P
Weston (and wayland in general ) are a boon to the embedded world.
We are regularly asked to do systems with very precise placement for
different windows coming from different apps
(think of a car, where the map application is usually an html5
in-browser application, but you can swith to air-conditionning control
which is a hand-made Qt application, and the the back camera which is a
separate Qt+Gstreamer application)
In the bad-old days, we would have to play with X and window-managers
like Awesome to do that (or write our own window manager which is... hell)
Now, we have weston which is very good at dealing with that (thx IVI
mode) or we can write or own compositor which is almost as easy as
writing a normal GUI application (qtcompositor, mainly)
A bit offtopic here, sorry about that.
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Not able to start Weston dependent application
Pekka : is the notify plugin already upstreamed ? if yes, loading it and setting Type=notify might work... On 31/10/2018 11:45, Lennart Poettering wrote: On Mi, 31.10.18 15:26, deepan muthusamy (deepan.m2...@gmail.com) wrote: I added both after and requires.What you meant by security feature?@rosan Type I made as simple.@ Lennart That's not going to work. If you use Type=simple, then system will consider the service to be up as soon as systemd called fork(). Unless weston uses socket activation this is definitely not the point in time where its IPC APIs are usable yet. Lennart -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Not able to start Weston dependent application
socket-activated weston ? nice :) Why does weston require logind ? I work in the embedded world and we usually disable logind entirely (no users in the "human user" meaning of the term) On 31/10/2018 11:14, Pekka Paalanen wrote: On Wed, 31 Oct 2018 15:26:06 +0530 deepan muthusamy wrote: I added both after and requires.What you meant by security feature?@rosan Type I made as simple.@ Lennart Hi Deepan, you really should follow the documentation added by this MR: https://gitlab.freedesktop.org/wayland/weston/merge_requests/39/diffs Weston with Type=simple cannot be reliable. Instead, you are intended to use the Weston plugin that integrates explicitly with systemd. Examples are in that MR. Thanks, pq On Wed, 31 Oct 2018, 1:45 pm Jérémy Rosen, wrote: Did you add an "After=" too ? you need both a Requires= and an After= Did you activate any security feature that might hide the wayland socket from app2 ? On 31/10/2018 08:21, deepan muthusamy wrote: Hi, I started app1(this is a UI application) as system service . I started app2( this is Weston ) also as system service. But in different tty(tty7). App1 is depended on app2 to start. I added that dependency. App2 is started but app1 not able to find that dependency. Iam getting error as not able to find weston. If I start both manually, it's working fine. -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Not able to start Weston dependent application
Did you add an "After=" too ? you need both a Requires= and an After=
Did you activate any security feature that might hide the wayland socket
from app2 ?
On 31/10/2018 08:21, deepan muthusamy wrote:
Hi,
I started app1(this is a UI application) as system service .
I started app2( this is Weston ) also as system service. But in
different tty(tty7).
App1 is depended on app2 to start.
I added that dependency.
App2 is started but app1 not able to find that dependency. Iam getting
error as not able to find weston.
If I start both manually, it's working fine.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Default on failure dependencies
This all makes me wonder whether a different approach to all of this wouldn't be better: maybe we should just consider this a logging problem: let's make sure we log a recognizable log message (i.e. a structured journal message with a well-defined MESSAGE_ID=) whenever a service fails. With that in place it should be relatively easy to write a system service that can run during regular system uptime and can look in the journal for all failures, including getting live notifications when something happens. Moreover, this resolves the problems during early and late boot: the "cursor" logic of the journal allows such a service to know exactly which failures it already processed and which ones are still left, and it can process all failures that took place while it was not running. Does that make sense? Could this be generalized to "a structured message whenever a unit changes state" or would that be too verbose ? I'm asking because that would be very usefull for post-mortem diagnostics, statup timings and that sort of stuff... Lennart -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Enforce limitations on portable services
Once enabled, a portable service is a normal service. You can enforce limits with all the usual tools, in particular drop-ins. On 04/10/2018 00:06, Gervais, Francois wrote: Hi, I'd like to know if the system administrator that attaches the portable service is able to enforce limits like cpu and memory usage over the service? A bit like when specifying the profile. Thank you ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Are there repeating monotonic timers?
You can put multiple criterion in a single .timer In your case, combining OnBootSec and OnUnitActiveSec should do what you want... HTH Jeremy On 03/09/2018 17:28, Wojtek Swiatek wrote: Hello everyone I would like to have a timer which runs every 60 seconds after the machine is booted. I thought that OnBootSec would be the right parameter but this is s a one shot call - it starts 60 seconds after the boot and then the service is done (does not restart ever) Is there a way to start a service every 60 seconds (this is an example), short of using OnCalendar and fixed times (including /x notation, but then end up at fixed dates/times anyway)? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Select on value of log message
I *think* that it's deactivated in debian because journalctl is a core
package and debian doesn't want to pull the regex library into it's core...
not sure, though. They'll probably tell you in the bug report you opened.
On 30/08/2018 15:41, Simon McVittie wrote:
On Thu, 30 Aug 2018 at 12:48:02 +0200, Cecil Westerhof wrote:
Posted the problem in a Debian newsgroup.
Please send all Debian-specific bug reports and feature requests to its bug
tracking system <https://www.debian.org/Bugs/>, filed against the package
that has the bug or is missing the feature. It's a big project, and posts
in other venues (newsgroups, mailing lists, IRC channels, forums, bathroom
walls, etc.) are likely to get lost, or not be read by the right people who
would do the work.
Thanks,
smcv
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Select on value of log message
unfortunately, regex in journalctl is an optional feature that is
decided at compile time.
Your distro probably did not compile that support. The best approch
would be to open a feature request
on your distro's bugtracker.
Alternatively you can recompile systemd yourself and add that support,
but that's a bit more complicated
(btw, you only replied to me, not the mailing list. Not a big deal, just
pointing it out so you don't forward further questions just to me)
On 30/08/2018 12:02, Cecil Westerhof wrote:
2018-08-30 9:57 GMT+02:00 Jérémy Rosen :
One of the big advantage of --grep compared to |grep is that it returns
the whole message, not just the line containig your regex
so you can combine it with "-o verbose" and get all the info on the
message easily
That makes it even more interesting.
I need to know why I get:
Compiled without pattern matching support
and what to do about it.
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Select on value of log message
One of the big advantage of --grep compared to |grep is that it returns
the whole message, not just the line containig your regex
so you can combine it with "-o verbose" and get all the info on the
message easily
On 29/08/2018 20:09, Uoti Urpala wrote:
On Wed, 2018-08-29 at 19:49 +0200, Cecil Westerhof wrote:
There are a lot of ways you can select the output you get from
journalctl, but it seems you cannot select on the message itself.
That is why I need to do something like:
journalctl | grep 'Database is locked'
Is this true, or am I overlooking something?
Since version 237, journalctl has had a --grep option.
Message text is not indexed, so performance-wise this still requires
going through all messages (as limited by other options).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to create minimal portable services environments?
I know that this is not the usual answer to that sort of question but you should try buildroot, rather than base yourself on debian. When you deactivate the kernel and busybox (it's done through a menuconfig type interface) you will get the minimal type of system you want. On 29/08/2018 12:24, Wojtek Swiatek wrote: Hello everyone, v239 brought in portable services (a good description is at http://0pointer.net/blog/walkthrough-for-portable-services.html) and while I still cannot make it work (I do not have a /usr/lib/systemd/portablectl despite having systemd --version reporting 239, but this is going to be a separate question) I wanted to understand how to build a minimal portable service. A practical example could be dnsmasq. It is provided as a package and depends (apt show dnsmasq) on netbase, dnsmasq-base, init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6). These packages may further depend on something else. It also brings in a set of files into the system: root@srv ~# dpkg-query -L dnsmasq /. /etc /etc/default /etc/default/dnsmasq /etc/dnsmasq.conf /etc/dnsmasq.d /etc/dnsmasq.d/README /etc/init.d /etc/init.d/dnsmasq /etc/insserv.conf.d /etc/insserv.conf.d/dnsmasq /etc/resolvconf /etc/resolvconf/update.d /etc/resolvconf/update.d/dnsmasq /lib /lib/systemd /lib/systemd/system /lib/systemd/system/dnsmasq.service /usr /usr/lib /usr/lib/resolvconf /usr/lib/resolvconf/dpkg-event.d /usr/lib/resolvconf/dpkg-event.d/dnsmasq /usr/share /usr/share/dnsmasq /usr/share/dnsmasq/installed-marker /usr/share/doc /usr/share/doc/dnsmasq Some of these are existing directories, some new ones and then there are files (new, but possibly existing as well). *How should I create a filesystem which has only the files required by the packages (= the ones it brings in, as well as all the dependencies)?* I know that I can dbootstrap a new system and install there dnsmasq - and then hopefully use this as the tree to be attached via portablectl. This however means that I do not have a "dnsmasq" portable service but rather a "bionic install with dnsmasq installed on top". The main reason for me to use portable service is to create small packages which encompass my service, to be mounted on a more or less base core OS install (say, minimal bionic). This would allow to get rid of several nspawn containers which do exactly this (base OS + a package installed on top). One of the ideas I had (but which seems very wrong) is to have a copy of the core OS, then in another copy install the required packages, and then make a diff of the two directories. But this looks horrible and is hardly maintainable. I would very much appreciate any pointers or hints on how to approach this. Wojtek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd service not connecting to session dbus
There are two types of systemd instances * system instance (PID1) which controls the machine as a whole * user instances that are started when the user logs in. You seem to have a system service (started by the system session). A system service can't (easily) access the user bus. The session bus is started by the user instance when the user login. If the user hasn't logged in yet, the bus isn't started. Moreover, the user bus is found via an environment variable, which is not set for system services (even when User= is used) What are you trying to do exactly ? should your service be a session service ? Regards Jeremy On 13/08/2018 09:17, Deepan Muthusamy wrote: I have an application which has to communicate with session dbus. If I start my application binary manually or start using Init.d, it is connecting to session d-bus. But if I start my application through systemd, it is failing to start. I tried to start using systemctl start my-service-name, this time also it is failing. And also I go through the answer given by keithel in https://serverfault.com/questions/892465/starting-systemd-services-sharing-a-session-d-bus-on-headless-system . Still Iam facing the same error. The .service fail is as follows: [Unit] Requires= dbus.socket After= dbus.socket [Service] Type=dbus BusName=org.client ExecStart=/usr/local/bin/myExe TimeoutSec=300 WatchdogSec=20 [Install] WantedBy=basic.target Operating system: Ubuntu 16.04 (64-bit) DEEPAN MUTHUSAMY, TATA CONSULTANCY SERVICE, mobile no: +91 8012309210 =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Playground ...
Very nice... I am writing a systemd course and I am missing exercises and samples... I'll definitely add that to my "interesting website" slide and use it at various places... On 01/07/2018 16:19, Bruno Vernay wrote: Hi, I created a few examples on various systemd features and more to easily test and "play" https://gitlab.com/BrunoVernay/systemd-playground/ My hope is to get feedback, since there are surely many things to improve. (while keeping it simple) I put links to similar projects, if I missed some, let me know. Regards Bruno ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Dealing with read-only rootfs
Hello everybody
I am trying to understand the recommanded way to deal with read-only
rootfs...
my understanding is that (slightly simplified)
* /run must be a tmpfs
* /var must be writable, and will usually be persistant (can be a tmpfs too)
* everything else can be read-only
My problem comes with populating an empty /var. There seems to be hints
to a systemd-provided mechanism to do that, but I can't find any
documentation for it
Apparently, tmpfiles.d should copy the content from /usr/share/factory
to /var when /var is empty, but I can't find what actually implements that
* is it dynamically added in /run ?
* is it just a recommanded way, and I have to implemented myself ? if
yes, is the directory /usr/share/factory documented anywhere ?
* what qualifies as "empty /var" ? (this is mostly about being robust to
power-loss during the copying of /var)
Any hints would be welcomed
thx
Jeremy
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] getgroups returning a diferent result
Partial answer, I don't know all the details... We are all taught in school that each unix user belongs to to a certain number of groups, and that is defined in /etc/passwd. That's kinda true, but it's an oversimplification. Each PROCESS has a user and a set of groups. Those groups are set when login (or whoever does the login process) switch from running as root to running as your user. At that point, it will explicitely read /etc/passwd, set the correct groups then switch to the final UID (which can't change groups anymore) This is the normal process when you login, but its a convention, not something that is enforced by the kernel. IIUC systemd does not do that for services. Services only have a UID, a main GID but no supplementary GIDs. Supplementary GID must be set explicitely with SupplementaryGroups= in [Service] They won't be read from /etc/passwd That's my understanding, at least, someone else might know better... HTH Jérémy On 15/06/2018 06:35, aleivag wrote: hi systemd'ers , i'm sure this is known, but for the life of me i cant seems to know why. tldr; aparently i loose all auxiliary groups of root when i execute a unit. i'll explain (i try this on v238). when i'm logged in as root, and i execute `id` i get all the groups that root belong to. but when i do the same in a systemd unit (e.g. under a transien unit, a la systemd-run) i loose all groups. i suspect that this is because the getgroups system call returns a different value, but for the life of me, i don't know why or how. i'll show on my normal bash ``` [homex ~]# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log) ``` i get all the groups, but if i run it with systemd-run ``` [homex ~]# systemd-run --pty id Running as unit: run-u207.service Press ^] three times within 1s to disconnect TTY. uid=0(root) gid=0(root) groups=0(root) ``` the only group i see is root, now for the semi weird part, if i execute `id root`, i do get all the groups ``` [homex ~]# systemd-run --pty id root Running as unit: run-u220.service Press ^] three times within 1s to disconnect TTY. uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log) ``` this is because getgroups return a diferent value if i'm in the unit or logged in ``` [homex ~]# strace id 2>&1 | grep getgroups getgroups(0, NULL) = 8 getgroups(8, [0, 1, 2, 3, 4, 6, 10, 19]) = 8 [homex ~]# systemd-run --pty strace id 2>&1 | grep getgroups getgroups(0, NULL) = 0 getgroups(0, [])= 0 ``` and the reson why i gett all the groups when i execute `id root`, is because that does not ask for groups, but call libnss instead ``` [homex ~]# systemd-run --pty strace id root 2>&1 | grep getgroups [homex ~]# systemd-run --pty strace id root 2>&1 | grep libnss openat(AT_FDCWD, "/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libnss_mymachines.so.2", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 3 ``` i guess i just wanna understand why this is, why this system call return different values if i'm in bash or if i'm in a unit. thanks guys! Alvaro Leiva Geisse ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding support for "systemctl reboot --bootmenu" ?
Since how to tell $bootloader to show its menu will be bootloader specific I'm thinking about using a special target for this, which gets started before doing the reboot and then bootloaders can drop a (oneshot) .service file in that target which does whatever is necessary to get the bootmenu next boot. Yes please, do not hardcode any UEFI specific ways to do stuff... Embedded systems have all sorts of bootloader (U-Boot and barebox are the most common but not the only ones) and we really need a way to plug into that... So is this something worth considering? Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a service *just* before unmounting filesystems
We solve a problem which is kinda similar in the embedded world when we do A/B update I'll describe how we do it so you see if this can help * Have a single "last boot went wrong" flag When grub starts * if the flag is set, show the boot menu (or a timer) * if the flag is not set * skip the menu, don't initialize USB, fastboot * set the flag. * At some point during the boot (late enough that it is possible to get a console) reset the flag. this way, your system is "unstable" : either you reach the point where a console is available or you will have a menu at the next reboot. The trick is to have grub first read the flag then set it to "bad" for the next boot. Linux set it to "good" if the boot was good enough Hope this help... Jérémy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timed out waiting for device dev-mmcblkp1.device
On 23/05/2018 13:50, Mantas Mikulėnas wrote: On Wed, May 23, 2018 at 2:37 PM Belisko Marek <marek.beli...@gmail.com> wrote: Hello, I'm using system 234 build by yocto for BeagleBoneBlack. I ave some strange issue that systemd start timeout because cannot find dev node (which is obviously non existing). Snippet: [ TIME ] Timed out waiting for device dev-mmcblkp1.device. [DEPEND] Dependency failed for /boot. [DEPEND] Dependency failed for Local File Systems. Device /dev/mmcblkp1 (mounted to /boot) was added to fstab (no idea which component did that). When removed from fstab boot works as expected. That's normal then. If a device is in fstab, systemd will try to mount it, because that's what fstab does. (I assume the name was supposed to be "mmcblk0p1" instead?) Are you using a yocto-generated image by any chance ? there is a bug in yocto that does that for some MACHINE (I'm not sure which one) I can't remember what the problem was, off the top of my head, but it's a yocto-side problem... if you change the line to mmcblk0p1, does everything works as expected ? Cheers Jérémy fstab has the "*nofail*" flag to mark the entry as not-required (with it set, systemd will just wait "in background" instead of failing), "noauto" to disable auto-mounting completely, and "x-systemd.automount" to delay mounting until first access. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DynamicUsers and read-only /var
hmm, I think you could have the whole /var as a tmpfs and use systemd-tmpfiles (man:tmpfiles.d) to initialize /var at startup by copying some template directory from a read-only location (typicalli in /usr) On 16/05/2018 13:29, Antoine Pietri wrote: Hi, Our organization uses a diskless setup to boot hundreds of machines using a read-only NFS export of their common rootfs. To be able to run services that need to write in /var, we can't just have /var as a tmpfs, because it contains files installed by packages that are required by some services to run. Our current solution was to have /var in read-only, but have a list of directories where some services actually write (/var/log, /var/spool/mail, etc) and mount them as tmpfs. This year, some services like systemd-timesyncd are shipped with DynamicUser=yes by default in our distribution (Archlinux), which means the above solution no longer works. My understanding is that systemd requires a writable /var to be able to symlink the state directory the first time it is launched. Our only option here, if we don't want to manually disable dynamic users in all the services, seems to be to mount /var in a copy-on-write overlayfs. We could do that, but it's a bit cutting edge and dangerous for us. Two years ago, overlayfs didn't even support nfs as its lower directory, that's why we avoided it so far. As I know you don't like to add requirements to have a writable /var, I'd love to have your input on this issue! Is there anything we missed that would allow us to keep using dynamic user services with a read-only /var, or do we have to use the overlay solution? Thanks, -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] `Found ordering cycle on _SERVICE_` loops due to `local-fs.target` with `Requires` instead of `Wants` for mounts generated from `/etc/fstab`
Ok, there are a couple of tools that have not be mentionned.. "systemd-analyze verify " will check all sorts of stuff on a service, including checking recursively the deps and finding ordering cycles systemctl list-dependencies can show ordering/req dependencies, up or down, recursively or not to be completely honest, I never use dot for cycles I sometime read/grep the .dot file itself, but I never generate the image... systemd-analyze is my favorite tool for that sort of problems On 27/04/2018 06:01, Andrei Borzenkov wrote: 26.04.2018 23:20, John Florian пишет: On 2018-04-26 16:04, John Florian wrote: On 2018-04-25 04:53, Lennart Poettering wrote: There have been requests in improving the cycle breaking algorithm, but not much has been done in this area, since it's not clear what can be done. Ultimately it's just polishing a broken situation, and the better way out is to fix things properly, i.e. just correct the cycle in the dependencies in the first place. Having been the author of numerous custom services that are intended to wedge into those provided by systemd/Fedora I've faced resolving these several times and I've never felt all that competent at the task. Lennart, you were immensely helpful on one occasion by pointing me to `systemctl show FOO` but even then hunting the problem down was far from simple (for me). I've done the dot/graphviz thing and found it just as useless to me as when I've tried applying it to Puppet's ordering/dependency looping. I'm not blaming those tools (or systemd) because I'm well aware much of the problem is my inability to use them effectively. The graphs always seem to be overly simple and revealing no problem or overly detailed and obscuring the problem. Compound that with "an arrow pointing this way means what exactly?" Is there anything else that could be done to make hunting these loops down easier? Is there an example of any product that has a similar situation where they excel at helping the developer? Or are we already there and I just need more practice? I'm sure part of my struggle is just not encountering these very regularly and integrating into much that I'm only partly familiar with, but the result is the same, trepidation and loathing. Since I hate to grumble w/o so much as offering any possible suggestions... It seems like it might be helpful to have something like `systemctl show` but only dumping the properties used for ordering and dependencies. Ideally, only ordering OR dependencies as the case warrants and for all units involved, but only those units. Well, you could use "systemctl show -p Id -p After -p Before" but the problem is to find the correct unit set. You really need something that simulates transaction and evaluates dependencies like systemd does it. Note that systemd should print offending cycle when it hits it: апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found ordering cycle on foo.service/start апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found dependency on bar.service/start апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found dependency on baz.service/start апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found dependency on foo.service/start апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Breaking ordering cycle by deleting job baz.service/start It would be helpful it if additionally printed kind of dependency (like foo.service is After bar.service) because this is by far not obvious for average user. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start service in multi-user.target but don't stop it on isolate
et Conflicts=shutdown.target Before=multi-user.target shutdown.target After=basic.target systemd-journald.socket system.slice Description=watchdog daemon LoadState=loaded ActiveState=inactive SubState=dead FragmentPath=/usr/lib/systemd/system/watchdog.service DropInPaths=/etc/systemd/system/watchdog.service.d/override.conf UnitFileState=enabled UnitFilePreset=disabled InactiveExitTimestamp=Mon 2018-03-19 13:42:22 CET InactiveExitTimestampMonotonic=14539954 ActiveEnterTimestamp=Mon 2018-03-19 13:42:22 CET ActiveEnterTimestampMonotonic=15052358 ActiveExitTimestamp=Mon 2018-03-19 13:44:02 CET ActiveExitTimestampMonotonic=114543976 InactiveEnterTimestamp=Mon 2018-03-19 13:44:07 CET InactiveEnterTimestampMonotonic=119544801 CanStart=yes CanStop=yes CanReload=no CanIsolate=no StopWhenUnneeded=no RefuseManualStart=no RefuseManualStop=no AllowIsolate=no DefaultDependencies=yes OnFailureJobMode=replace IgnoreOnIsolate=yes IgnoreOnSnapshot=no NeedDaemonReload=no JobTimeoutUSec=0 JobTimeoutAction=none ConditionResult=yes AssertResult=yes ConditionTimestamp=Mon 2018-03-19 13:42:22 CET ConditionTimestampMonotonic=14539719 AssertTimestamp=Mon 2018-03-19 13:42:22 CET AssertTimestampMonotonic=14539719 Transient=no -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] alternative approach to waiting for system time to be set
Maybe start a github pull-request ? things seems to be less forgotten that way. since your code already exist, creating a first PR should not be too much work... On 19/03/2018 02:45, Peter A. Bigot wrote: Like others I'd like to use systemd to defer starting a service until the system time has been set accurately. Previous approaches to resolving issue #5097 don't seem to be going anywhere. https://github.com/pabigot/timesyncwait has my proposed solution: a standalone service that blocks until adjtimex(2) confirms that something has told the kernel its realtime clock is synchronized. It also provides a new time-synchronized.target so it can be installed alongside an unmodified timesyncd. Initial tests show this meets my needs. I'd be willing to rework it as a patch to systemd if there's consensus the approach is reasonable. Peter Mar 15 17:14:17 raspberrypi3 systemd[1]: Starting Wait Until Kernel Time Synchronized... Mar 15 17:14:17 raspberrypi3 timesyncwait[107]: adjtime state 5 status 40 time 1521134057.408590 Mar 19 01:04:35 raspberrypi3 timesyncwait[107]: adjtime state 0 status 2000 time 1521421475.316852 Mar 19 01:04:35 raspberrypi3 systemd[1]: Started Wait Until Kernel Time Synchronized. References: * https://github.com/systemd/systemd/issues/5097 * https://github.com/LukeShu/systemd-timesyncd-wait * https://lists.freedesktop.org/archives/systemd-devel/2014-November/025131.html * https://lists.freedesktop.org/archives/systemd-devel/2017-May/038952.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Create a target unit to start & stop a group of services
On 27/02/2018 02:49, 林自均 wrote: Hi both Michal, Thank you for the quick responses! I think I will keep on using the tedious PartOf= directive. However, may I ask why ConsistsOf= is readonly? If I can use it in my "my-apps.target", that would be great. Because "ConsistsOf" doesn't exist in the way you think it does... Every relation between units (Wants, Before, PartOf) needs to have an internal, reverse relation for accounting purpose That reverse relation is usually an internal detail, but it is handy to expose it in "systemctl show" & co. So that's what you see, an internal property exposed for ease-of-use. not an external, user configurable property John Lin Michal Koutný <mkou...@suse.com> 於 2018年2月26日 週一 下午7:28寫道： On 02/26/2018 11:08 AM, Michal Sekletar wrote: Unfortunately, we don't have a dependency (AFAIK) that only propagates stop actions. FTR (not helpful for the original problem), there exists ConsistsOf= as an inverse of PartOf= dependency. However, it's read only currently (or strictly speaking, writable through the PartOf= endpoint). Michal ___ 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 -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Automatically stop a service when a dependent service exits
StopWhenUnneeded in man:systemd.unit is probably what you want... On 15/02/2018 10:06, Jakob Schöttl wrote: Hi, can I ask a configuration question here? I have an upload.service, started by an upload.timer. The upload.service has a Require=ssh-tunnel.service (After= is also set). When the upload.service is finished how can I make systemd to also stop the ssh-tunnel.service? Currently I use systemctl stop ssh-tunnel.service in the upload script. But since the upload.service has User=, I also have to configure sudo to allow my script to stop the service. Is there already a systemd solution for this problem? - Jakob ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why is systemd-run --scope synchronous?
I would understand the question as : "why is the foreground/background concept linked to the concept of scope ?" for most people --scope means "run in the background" which is only a side effect of what that command really does. Maybe there is a need of some doc clarification, or get non-scope runs also be foreground and leave backgrounding to the shell... Anyway, the first step is to understand why there is this difference of behaviour in the first place... On 05/02/2018 14:59, Lennart Poettering wrote: On Fr, 02.02.18 19:00, worz (w...@tuta.io) wrote: Hello, I was wondering why systemd-run --scope needs to be synchronous, it would be nice if someone could explain what happens under the hood, and what prevents it from just putting the process in the scope, and maybe just call the Abandon() method on the slice object's org.freedesktop.systemd1.Scope interface, when for example it is used in combination with --user, the scope is under user@1000.service, so it should be cleaned up as soon as the service manager goes away? Note that there's not a specific usecase to cover here, I am just interested in knowing why it isn't the other way. Hmm, I am not sure what you precisely mean by "synchronous" in this context? Is this about the bus calls being issued synchronously? We do that so that at the time the user-specified command is executed we know for sure that the resource limits and other things are in effect on it. If we'd asynchronously register the scope and would already execute the user's command, then these resource limits would only be applied asynchronously, i.e. at some later point too, which is generally not what is intended. Or are you using the word "synchronous" in the context of foreground vs. background? I.e. you want your process to be forked into the background? That's actually done by default by systemd-run when you don't use "--scope", where the executed process is moved into into the background as a service. Note that "systemd-run --scope" is little more than an execve()-wrapper: if you want the whole thing to be running as a shell managed background process, then suffix the line in "&" like you would normally do too, when you don't use "systemd-run"... But then again, I am not sure what you actually are looking for so maybe my answers above completely miss the point... Lennart -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about a random UDP port on rpcbind 0.2.3 started by systemd
if you have the mentionned file (/usr/lib/systemd/system/rpcbind.socket) then systemd will open whatever port is described in there and pass it pre-opened to rpcbind. systemd has no idea what that port is for and the file mentionned above was provided to systemd by the rpcbind package. You should really ask the rpcbind people what it is for, systemd is just the messenger here... On 26/01/2018 03:48, Bao Nguyen wrote: Hello evryone, I would like to ask you a question regarding the new random UDP port in rpcbind 0.2.3. In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through rpcbind.service, then I do netstat udp0 0 0.0.0.0:111 0.0.0.0:* 10408/rpcbind udp0 0 0.0.0.0:831 0.0.0.0:* 10408/rpcbind udp6 0 0 :::111 :::* 10408/rpcbind udp6 0 0 :::831 :::* 10408/rpcbind The rpcbind does not only listen on port 111 but also on a random udp port "831" in this case, this port is changed every time the rpcbind service retstarts. And it listens on 0.0.0.0 so it opens a hole on security. I have looked into the change of rpcbind 0.2.3 and found the change " rpcbind: add support for systemd socket activation", it calls a function sd_listen_fds, I do not know much about systemd socket activation programming, does the "831" port is generated from rpcbind to communicate with systemd socket activation? Could you please let me know what this port is for and is there any way to avoid that like force it listen on a internal interface rather than on any interfaces like that? As the rpcbind is started from systemd so "-h" option is invalid as the man page says: -h Specify specific IP addresses to bind to for UDP requests. This option may be specified multiple times and can be used to restrict the interfaces rpcbind will respond to. Note that when rpcbind is controlled via sys- temd's socket activation, the -h option is ignored. In this case, you need to edit the ListenStream and ListenDgram definitions in /usr/lib/systemd/system/rpcbind.socket instead. Thanks a lot, Brs, Bao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Stopping services started by Systemd socket
that's not really an answer to your question but...
have you looked at systemd-socket-proxyd ? it's a simple program that is
meant to be started by a socket and will redirect all traffic to another
local port.
Properly used it allows a traditional network daemon to be started on
demand. I won't go in the details, it's pretty well explained in the man
page.
Depending on why you are converting your software, it could be something
interesting to look at...
On 23/01/2018 08:18, Mantas Mikulėnas wrote:
On Tue, Jan 23, 2018 at 3:06 AM, Liam Kelly <liamkell...@gmail.com> wrote:
How does Systemd communicate to socket activated application that the
connection has been closed? How can I modify my application to detect this
event if it cannot be configured to be closed automatically?
We are trying to add network support to legacy code using Systemd sockets.
Using the 0pointer tutorials, we were able to configure a listening TCP
port and launch an instance of the application when a TCP connection came
in. The problem is that when the connection is closed, the service is still
running.
The systemct list-units and netstat -tuapn outputs are what you would
expect when the connection is established
systemctl list-units:
myapp@5-192.168.0.75:10001-192.168.210.102:19983.service loaded
active running My App
netstat -tuapn:
tcp0 0 192.168.0.75:10001 192.168.210.102:19983
ESTABLISHED 1/init
However, once the client closes the connection, the socket is closed and
removed, but the application is still running as a service:
It is no different from any other type of networked service. Whether you
opened the socket yourself, or received it from a superserver, makes no
difference.
For example, if your program uses poll(), the kernel reports POLLHUP on a
closed socket. If the program uses read() or recv(), 0 bytes indicates that
the socket is closed. If the program uses simple stdio (inetd style), it's
enough to check for EOF on reads from stdin.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd_watchdog_enabled: how to use when forking process?
Alternatively, NotifyAccess= in [Service allows other processes to ping the watchdog, but Simon is right... forking is not needed for systemd. On 19/01/2018 18:41, Simon McVittie wrote: On Fri, 19 Jan 2018 at 17:22:51 +, philip is hungry wrote: however if i run the forkme function (to put process in the background) it behaves as follows: Jan 18 15:06:25 thinkpad waitonly[11228]: Return from forkme = 11228 Jan 18 15:06:25 thinkpad waitonly[11228]: Return from lockme = 0 Jan 18 15:06:25 thinkpad waitonly[11228]: PID to compare with watchdog_pid: 11228 systemd tells your service which process it expects to be sending keepalives ($WATCHDOG_PID), and only accepts keepalives from that process. The forked child process has some other process ID, so sd_watchdog_enabled() returns false for it. If you want to use the watchdog, don't fork and go to the background: it's unnecessary for systemd services. To notify systemd that your process is ready to receive requests (which was done via the double-fork trick in init-script-based init systems), a daemon that natively supports systemd features can use sd_notify() and Type=notify. If you want your service to continue to support non-systemd init systems, you might want to add a --no-fork command-line option and make the systemd unit's ExecStart use that option. For example, that's how it works for dbus-daemon, which needs to continue to default to forking for compatibility with what it does on non-Linux OSs or non-systemd init. Or, if your service will only ever run under systemd, you can make it not fork/background itself at all. smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl start second.service first.service
I had a quick look at the systemd dbus API (which I assume is close to what systemctl uses) and there are no easy way to queue multiple "starts" into one job There is a single StartUnit (+varient) method which can only take a single unit. no queuing mechanism, way to create ajob without triggering it or other workaround So yes, to get this to work as expected a new API probably needs to be added. Alternatively, systemctl could create an Transient, temporary unit with the correct relationship (Wants, Conflicts, ReloadPropagatedFrom) and start that unit, pulling in the ones on the command line. Not sure if that's a good approch. Just stating that it's possible... On 12/01/2018 14:11, Simon McVittie wrote: On Thu, 11 Jan 2018 at 21:41:54 +0100, Reindl Harald wrote: come on - nobody cares about this bullshit bingo about what are jobs, units and services Please try to be polite when you are in a situation where you could be perceived as representing a community. Responses like this to discussion of a technical issue do not help systemd's reputation, and using jargon terms precisely is a useful way to describe how code works. For what it's worth, I think I agree with the technical point you were making, which (if I understand correctly) is that it would be better for each "systemctl start" invocation to create a single transaction (job) that will start all the units named on the command-line in an order chosen by the systemd manager to respect their Before/After ordering. Thanks, smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to start a task after system boot but only on specific days using systemd.timer
On 10/01/2018 05:17, Andrei Borzenkov wrote: 09.01.2018 22:28, Joerg Diederich пишет: Hello, I have a little (perhaps strange) requirement: I want to execute a script about five minutes after system boot, but only on specific weekdays (e. g. Sundays) using systemd.timer. I tried a combination of OnBootSec and OnCalendar like OnBootSec=5m OnCalendar=Sun but this doesn't work. Well, it works but not they way you want it :) As documented, multiple directives are additive - timer will trigger when any of them elapses. May be it could be expressed more obviously. There is a workaround but it's a bit more complicated than it should be : use multiple timers. timer1.timer ; OnBootSec=5m timer1.service ; Wants=timer2 timer2.timer ; Oncalendar=Sun Note that you need the intermediate unit, you cant user Unit=timer2.timer in timer1.timer because a timer is not allowed to start another time (I don't know why) You can also have a look at https://github.com/systemd/systemd/pull/7023 where II suggested something similar for upstream Cheers Jérémy My script executes always after boot. I'm running systemd-228-38.1.x86_64 on SuSE LEAP 42.3. Of course, I can modify my script to ask for the current weekday, but I thought, it would be more elegant to configure it all together in the timer unit file. This would likely require new directive or at least new syntax. Timers define point in time, not period of time. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependencies on DBus activated services during shutdown
well, afaict from your description the information "A needs B" is totally implicit, there is no place where this info is available, so no way to pass that info to systemd. That means that the only way to fix that without explicitely telling someone about the dependency is to allow dbus to start units while its shutdown is pending this seems to be explicitely forbidden, so my guess is that there are very good reasons for that and there is little chances that there is a workaround... so, i'm not an expert, but I would be very suprised if there was a way to do that... an explicit "allow startup during termination" flag in the auto-activation .service file could be a way around but I don't think such file exists... sorry On 08/01/2018 16:07, Michal Koutný wrote: Hello, I'd like to ask your opinion on the following situation. B.service exposes its API through D-Bus. A.service uses this API and thus it has a dependency on B.service. This is implicit though -- and we're happy we can rely on D-Bus activation and needn't to list all dependencies explicitly. As it comes, A.service needs B.service for proper termination. During the shutdown transaction there is unspecified ordering of the two (since the dependency is implicit only) and B.service is stopped before A.service. A.service would attempt to D-Bus-activate B.service but that is rejected because dbus-daemon will eventually stop too. Note this doesn't mean dbus-daemon is already handling SIGTERM, it's because a dbus-daemon stop job is pending [1]. A.service may thus cannot terminate properly. I know this could be circumvented by explicitly specifying After=b.service for the A.service but denies the elegance of the lazy (implicit) activation. Are there any better ways how to deal with this? Thanks, Michal Koutný P.S. FTR, in my case A.service=libvirtd.service and B.service=systemd-machined.service. [1] https://github.com/systemd/systemd/blob/master/src/core/dbus.c#L169 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using sysusers to setup a new system
Hello Sébastian
On 23/12/2017 00:33, Sébastien Luttringer wrote:
Hello,
On the way to rely on /systemd-sysusers/ to create *all* users in a
fresh Arch Linux installation, I'm stuck with two issues[1][2].
The key idea was to rely on /systemd-users/ to create them all and
start with empty passwd/group/shadow/gshadow files[3].
So, we moved all base user definitions in a /sysusers.d/arch.conf/
file; or better into the package which require them.
The first issue[1] is to be able to define the root user shell.
Currently, /sysusers.d///basic.conf/ provides a nologin shell, which
prevent root to login and execute commands (even via sudo). We cannot
override the /sysusers.d///basic.conf/ with a crafted version because
/systemd-sysusers/ doesn't support a shell definition in its format.
As a consequence, I added back root to passwd/group/shadow/gshadow[4].
So, what's the strategy about this? Should root user be an exception
and be defined somewhere else than others users because it requires a
valid shell?
sysusers is meant to create only system users, not human users... as
such, it doesn't allow you to set the shell, because system users should
never have a shell. Human users are usually created via some distro tool
at install time (adduser & co)
that's for the philosophical explanation of why you are doing something
that is not meant to be done... now let's be a bit more practical...
root is a very special user in many ways, and one of them is that it is
both a human and a system user... As such I would tend to think that the
proper way to deal with it is to either hardcode it in passwd/group or
to create it at install time.
Not really what you wanted to hear, I know, but root is really special,
and will need special-casing whatever solution you take...
The second issue[2] is about the lp group defined in
/sysusers.d///basic.conf/. Because the /cups/ Arch package set rights
on files based on the lp group it needs a static gid (pacman
requirement). lp defined in /sysusers.d///basic.conf/ is without
gid[5], so what's the best way to override it?
hmm, tricky... I see a couple of answers
1) open a RFE on github asking that the lp group be defined in a
base-lp.conf file, so it can be separately overriden (ideally with a patch)
2) just override the systemd-provided basic.conf with arch's version.
You are the distro maintainer, so it's ok to do that.
3) if you don't want to just replace basic.conf, you can create an
archbasic.conf file that would override just the lp group (in case of
double definition the lexicographycally first entry wins, and arch
starts with an a )
That will cause warnings, but that might be ok, depending on what
your exact constraints are..
Cheers
Jeremy
Cheers,
Sébastien "Seblu" Luttringer
[1] https://bugs.archlinux.org/task/56017
[2] https://bugs.archlinux.org/task/56818
[3] https://bugs.archlinux.org/task/45196
[4] I love it when a plan comes together ©
[5] https://bugs.archlinux.org/task/55793
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH weston] doc/systemd: system service example
ective is a workaround to a systemd bug, where the setup of the +# user session by PAM has some race condition, possibly leading to a failure. +# See README for more details. +After=session-c1.scope + +# Since we are part of the graphical session, make sure we are started before +# it is complete. +Before=graphical.target + +# Prevent starting on systems without virtual consoles, Weston requires one +# for now. +ConditionPathExists=/dev/tty0 + +[Service] + +# Requires systemd-notify.so Weston plugin. +Type=notify +ExecStart=/usr/bin/weston + +# Optional watchdog setup +TimeoutStartSec=60 +WatchdogSec=20 + +# The user to run Weston as. +User=westonuser + +# Set up a full user session for the user, required by Weston. +PAMName=login + +# A virtual terminal is needed. +TTYPath=/dev/tty7 +TTYReset=yes +TTYVHangup=yes +TTYVTDisallocate=yes + +# Fail to start if not controlling the tty. +StandardInput=tty-fail + +# Log this user with utmp, letting it show up with commands 'w' and 'who'. +UtmpIdentifier=tty7 +UtmpMode=user + +[install] +WantedBy=graphical.target -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] proper use of /run/{user/, }/systemd/private sockets
On 14/11/2017 04:26, aleivag wrote:
Hi all:
hope you guys are doing great!. So i have a few questions, hope this
is the best place for them.
I've been doing a lot of work with `sd-bus.h` (basically i've been
trying to bind it to other languages to then interact with systemd
natively).
I've been reading the man pages/blog post/general docs, but mostly the
src code. and i stumble across
https://github.com/systemd/systemd/blob/master/src/shared/bus-util.c#L598-L605
and saw that you can connect to systemd using the sockets, for root
would be `/run/systemd/private`, and for users something like
`/run/user//systemd/private` and this trigger lots of questions,
that i have not been able to answer, so here they are:
Question 1)
what would be the advantage of connecting through dbus instead of
directly through the socket?
the way i connect to systemd is with `sd_bus_open_system` but i can
also do
```
sd_bus_new();
sd_bus_set_address(bus, "unix:path=/run/systemd/private");
sd_bus_start(bus);
```
why (or when) would one be better than the other?
My understanding is that you should always connect through the normal
system dbus socket and not use systemd's private socket
The private socket (afaiu) is meant to be used only by systemctl. It
talks directly to systemd (without a dbus daemon) and is here to make
sure systemd and systemctl can communicate even when dbus is broken or
not started yet
question 2);
i also look that you can do the same with the user connections (and
this is mostly true when the --user flag is given, at least on
systemd-run), and you can connect to something like
`/run/user//systemd/private`, where `/run/user/` is
$XDG_RUNTIME_DIR, and i guess this is really the best form to connect
to systemd as a user, but is there any difference between using that
socket or doing `sd_bus_open_user`. ?
question 3)
systemd source code is pretty clear, really easy to learn from, also
sd-bus.h is incredible helpful and easy to use.
But the docs is good, don't get me wrong, but it could definitely use
more love. for instance the usage of the sockets
`/run/{user/uid,}/systemd/private`, is not documented anywhere that i
could find. is this intentional?, is this because this is a
implementation detail that may change in the future?. if so, what
would be the correct way to connect to systemd's socket?
i was particularly surprise that the sockets' path are hardcoded in
the code.
Yesn systemd private sockets are private and systemd does not want to
document private interfaces.
That being said, the system socket location is hardcoded not just in
systemd, but in the dbus specification itself. It won't change, so it 's
ok to hardcode it...
I didn't answer all your questions, but I hope the bits I know helped
Jeremy
if this parts have not just gotten into the docs, i would be more than
happy to submit the PR for the docs.
Thank you guys!
Alvaro Leiva
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding a .device reload on udev change
On 05/11/2017 07:45, Lennart Poettering wrote:
Ah, sorry for not reviewing this more timely. I didn't look into this
again mostly out of time constraints... Because we just did a release
I am not focussing so much on reviews, but try to write new code
instead. And when I do reviews anyway right now I usually start from
the top of the PR list...
No problem, it's just that, because the concept was already tested and
validated in a previous PR, I thought the review would go fast
And since I heard you complaining at least once that github
notifications had problems, I was wondering if I hadn't fallen in one of
those cases,
I'll simply wait for 236 then
As soon as we start preparing for the next release again I'll refocus
back on reviewing PRs, and unless I found the time to look at this one
earlier I'll definitely find it then.
Would it be possible to announce when you enter the "preparing for
release" phase ?
I don't think anybody needs this info strictly speaking, but it would be
handy for those of us that have PR waiting so we know there is a dealine
and we should respond quickly...
Thx
Jérémy
Sorry for the delay. And yes, we have too foo reviewers. Reviewing is
time consuming, and not the most grateful of tasks I figure, and much
like most free software projects in systemd we have to few
reviewers for the amount of patches we get...
Lennart
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Adding a .device reload on udev change
Hello everybody
I have written PR https://github.com/systemd/systemd/pull/6850 (opened)
and PR https://github.com/systemd/systemd/pull/6428 (closed)
Both of these PR were about having systemd generate a "reload" on
.device units to propagate to real services.
The first one was accepted, the concept was valid, but it caused a
regression and was partially reversed
I opened the second PR to track the regression and submit a version that
worked. That version has been around for some time but I have not
received any comment or no-go on it.
At this point I was wondering if there is a problem in the github
notification logic, or if my PR is being ignored because I originally
asked it to not be merged (regression testing)
So, just to be sure, is there a particular reason systemd is not
interested in the idea, or is this just a case of me being paranoid and
the devs having other stuff on their radar ?
Thx and sorry for the inconvinience
Jérémy
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a way to override the "Where" option in mount units?
you could mask the original unit and symlink it with a new name in /etc
you could probably use Alias= in the [Install] section to have that
automated at install time... not sure if that would work, some testing
is needed.
On 31/10/2017 11:19, Dennis Jacobfeuerborn wrote:
Hi,
I'm trying to set up a redundant nfs server but the problem I'm
currently running into is that I need to move the
/var/lib/nfs/rpc_pipefs mountpoint outside of /var/lib/nfs.
The original mountpoint is handled by
/usr/lib/systemd/system/var-lib-nfs-rpc_pipefs.mount which comes as part
of the nfs-utils RPM.
So my initial naive idea was to create a drop-in in /etc/systemd/system
and override the "Where" option but that's when I learned that this
option cannot differ from the mount unit filename.
This creates a dilemma for me since I shouldn't modify the original
mount unit both in principle and because it would mess up things
horribly when updating. Due to the limitations on the mount unit
filename I cannot create a drop-in directory either though so I'm not
sure what the appropriate way to handle this situation is.
The only way I can think of is to disable/mask the original mount unit
and create a completely new one or is there another way to deal with this?
Regards,
Dennis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>
20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS
email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu
Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>
Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Scheduling unit at reboot.target and shutdown.target
see man:bootup for the general architecture of shutdown and man:systemd-shutdown for how to add a script as the "ultimate phase" of the shutdown doing it with services is tricky, your approch will make it be called at shutdown but you did not specify "when" during shutdown, so systemd might schedule it at any point you could try to plug it in at the right place using some Before= and After= but if that command is the "real shutdown" command, i'd use the process described in systemd-shutdown regards Jérémy On 27/10/2017 11:43, D.S. Ljungmark wrote: So, I've got a piece of hardware I want to do a final handover to just around reboot.target / shutdown.target This will then cause the entire CPU and hardware allocated to it to actually drop power (and schedule re-power), so I don't want to do this earlier. Is it simply to do: [Unit] DefaultDependencies=no [Service] ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1 Type=oneshot [Install] WantedBy=reboot.target or am I missing something here? ( Perhaps the fact that systemd has already pivoted root to somewhere else?) //D.S. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- SMILE <http://www.smile.eu/> 20 rue des Jardins 92600 Asnières-sur-Seine *Jérémy ROSEN* Architecte technique Responsable de l'expertise Smile-ECS email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> phone +33141402967 url http://www.smile.eu Twitter <https://twitter.com/GroupeSmile> Facebook <https://www.facebook.com/smileopensource> LinkedIn <https://www.linkedin.com/company/smile> Github <https://github.com/Smile-SA> Découvrez l’univers Smile, rendez-vous sur smile.eu <http://smile.eu/?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to specify dynamic services/requirements
On 15/09/2017 07:27, Luiz Angelo Daros de Luca wrote: Thanks Jérémy, That was what I needed. I was afraid to be headed to the wrong way. Now that I know what to do, I need to know where and when. you could create a template (xendomains@.service <mailto:xendomains@.service>) and use drop-ins to do per-instance overrides (/etc/systemd/system/xendomains@vm1.service.d/append.conf) that would allow you to individualize each domain while keeping the common parts I would find a way to prevent a domain with no corresponding to start (maybe by not defining a mandatory key in the template) to make sure no rogue domains are created... I would use a template like xendomains@.service in order to specify common stuff. However, the config of which vm are enabled (autostart) is only available at boot time. Is a systemd generator the way to go? Is is there another way to define it? Also, should I use a service patch (like append.conf you mentioned) or simply directly create /run/.../xendomains@vm1.service? both method work... the first one allow to add stuff to the common template, the second to override more easily in the case of a VM that is totally different from the others... It would be trivial to define a template xendomains@.service and start services like "systemctl start xendomains@vm1.service", that would read /etc/xen/vm/vm1 and launch it. I just don't know how I could define dynamic dependency for that instance depending on the content of /etc/xen/vm/vm1. Execstartpre can check requirements and prevent a service to run but not wait for a resource to be available. It would be something like ExecRequires=. A generator is probably the way to go... generators can create ANY systemd configuration files, including templates, drop-ins and .wants directory You probably already found that, but in case you didn't, you should read the DESCRIPTION section of man:systemd.unit It describes all the ways you can add files to configure units In particular, if you want a service started at boot time, you need to create a default.target.wants/ directory and add a symbolic link to the unit to start in there. Populating such a directory at boot time with a generator might be the best approch for you... Instances seems to be created only when asked directly (systemctl start xendomains@vm1.service), which might be triggered by something like udev event. Is there anything like ExecListStartInstances=, ExecListRunningInstances=? see my answer above. There is no such thing, but generators can do the equivalent by creating a .wants link (as a side note, I don't know if you could do a "systemctl enable --runtime" from a generator. maybe someone else here would know) Generators can create something like that but they are triggered only at boot and daemon-reload. It would be interesting to somehow run "something like generators" when start/stop/status is called. what would be your use-case ? status is not "an event" nothing real happens on status start/stop can propagate stuff based on their parameters, but the services themselves are not meant to be dynamic... That being said, it might be possible to dinamically add dependencies to a unit via dbus and/or systemctl set-property, but I have never tried it, so you'll need to try and see From what I know about systemd, I'm thinking of something like a generator that will create services for all autostart and saved vm. The current script-based xendomains.service will run after all xendomains@.service instances. This way, a new enabled-after-boot vm would be started with "systemctl restart xendomains". I could use the existence of /etc/xen/auto/vm or /var/lib/xen/save/vm as requirement for xendomains@vm.service, in order to avoid to start a disabled-after-boot vm. However, this does not look like an elegant solution. Your requirements seems very complex (and, I have to admit, a bit hard to understand through e-mail) but I think that with a good understanding of templates and generators it can be solved elegantly * use templates to define how to start vms (common parts in the template, particularities in the instances) * add all boot-time depedencies via .wants directory via a generator (maybe usint systemctl enable if it can be run at generator-time, but i'm not sure it's possible) Hope this helps Jérémy Regards, -- Luiz Angelo Daros de Luca luizl...@gmail.com <mailto:luizl...@gmail.com> -- Logo <http://www.smile.fr/> 20 rue des Jardins 92600 Asnières-sur-Seine www.smile.fr <http://www.smile.fr/> *Jérémy ROSEN* Architecte technique Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> Tel : +33141402967 Facebook <https://www.facebook.com/smileopensource> Google%2B <http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn <https://www.linkedin.com/c
Re: [systemd-devel] How to specify dynamic services/requirements
On 13/09/2017 06:08, Luiz Angelo Daros de Luca wrote: Hello, I'm facing a problem with Xen machines that depends on MD devices. As I'm new to systemd world, I might not be seeing the clean solution. That's why I'm asking for an advice. MD devices are automatically detect by udev. If device state is safe, /dev/md/myraid is started. However, if the state is not safe (like a raid with a missing disk), udev starts mdadm-last-resort@.timer that tries to start the device anyway after 30s. As mdadm-last-resort conflicts with the device presence, it will not run if the required disk appears before 30s. Even with mdadm-last-resort running, MD device might still be usable, although degraded. Xen VM are started by xendomains.service, that simply calls a shell script like in SysV times. It start a bunch of VM in sequence. xendomains.service has only generic dependencies that let it run at a very early stage. I would cut that script in multiple services... but you mention doing that below, so I'm just saying I think it's the right way to go :) Now the problem: If for any reason, a MD device takes some seconds to appear (or even 30s as the last resort), xendomains will fail to start any machine that depends on that MD device. I'm extending manually xendomains.service to depend on a series of MD devices, that fixed the start order problem. However, I created new problems. First I had to frequently regenerate those "Requires" as machines are frequently started/migrated between hosts (I also consider using systemd generators). But worse, whenever a single MD device permanently fails, xendomains is never started and all those VM that does not use the failed MD never start. I though that maybe I could use instances (xendomains@vm1.service) to launch VM individually, each of them depending on those devices it uses. However, these instances would have to be dynamically generated based on its configuration (systemd generators from /etc/xen/vm/xxx.cfg?), either on boot, shutdown or simply periodically. The stop procedure will still be the same, calling the SysV script as systemd will not know about VM (re)started after boot. you could create a template (xendomains@.service) and use drop-ins to do per-instance overrides (/etc/systemd/system/xendomains@vm1.service.d/append.conf) that would allow you to individualize each domain while keeping the common parts I would find a way to prevent a domain with no corresponding to start (maybe by not defining a mandatory key in the template) to make sure no rogue domains are created... I even though about simply create an alternative xendomains.service that does not depend on any MD device and launch it using a systemd timer if the xendomains that depends on MD devices isn't started after 30s. It looks ugly but it might work. Regards, -- Luiz Angelo Daros de Luca luizl...@gmail.com <mailto:luizl...@gmail.com> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Logo <http://www.smile.fr/> 20 rue des Jardins 92600 Asnières-sur-Seine www.smile.fr <http://www.smile.fr/> *Jérémy ROSEN* Architecte technique Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> Tel : +33141402967 Facebook <https://www.facebook.com/smileopensource> Google%2B <http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn <https://www.linkedin.com/company/smile> Twitter <https://twitter.com/GroupeSmile> bandeaux_mail <http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Formatting Execstart= for readability
On 16/08/2017 10:31, Mantas Mikulėnas wrote:
On Wed, Aug 16, 2017 at 10:52 AM, Kai Hendry <hen...@webconverger.com
<mailto:hen...@webconverger.com>> wrote:
Hi there,
I maintain a service file with a lot of switches in the ExecStart
https://github.com/kaihendry/pingprom/blob/master/prometheus%40.service#L8
<https://github.com/kaihendry/pingprom/blob/master/prometheus%40.service#L8>
I want to almost document each switch ... e.g.
-storage.local.retention=8544h # keep data for a year
I know inline comments do *not* work in bash IIUC:
https://gist.github.com/kaihendry/ff751622c6454176837b1c340b5cfccb
<https://gist.github.com/kaihendry/ff751622c6454176837b1c340b5cfccb>
And similarly when I try break up lines on something like
https://s.natalian.org/2017-08-16/test.service
<https://s.natalian.org/2017-08-16/test.service>
[Service]
ExecStart=/usr/bin/curl -X POST
-d "fizz=systemd" # some docs
-d "some=else" # more docs
https://requestb.in/19v8a0m1
It also doesn't work. Am I missing a tool or way to better
format/document process arguments like I want?
Just put everything in a shell script. (That way you can test it
directly without systemd, too.)
Alternatively, you could documente everything in an EnvironmentFile that
sets an environment variable with all the parameters and documents in a
comment
Regards
Jérémy
--
With bash, you can use inline comments in arrays:
#!/usr/bin/env bash
args=(
-X POST # foo
-d "fizz=systemd" # some docs
-d "some=else" # more docs
https://requestb.in/foo
)
exec curl "${args[@]}"
--
Mantas Mikulėnas <graw...@gmail.com <mailto:graw...@gmail.com>>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Logo <http://www.smile.fr/>
20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr <http://www.smile.fr/>
*Jérémy ROSEN*
Architecte technique
Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
Tel : +33141402967
Facebook <https://www.facebook.com/smileopensource> Google%2B
<http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn
<https://www.linkedin.com/company/smile> Twitter
<https://twitter.com/GroupeSmile>
bandeaux_mail
<http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] question about system reboot and shutdown
Hi I have no problem with changing some code in microupsd so it behave in certain way. It is handling SIGTERM and other signals if needed. The problem for me is that SIGTERM is send to process during system reboot and system halt - so I need to differentiate between the two. SIGTERM is sent, by default, to all processes early during shutdown. You need to disable DefaultDependencies for your process to not recieve the default SIGTERM and then trigger it yourself with the WandedBy that was already described... Your daemon is a late-shutdown daemon, not a normal daemon. I think that deactivating default dependencies in this case makes sense. I strongly advice carefully reading the section on default dependencies in systemd.service, though... You will deactivate all default dependencies and you probably don't want that. You'll need to manually reactivate the other default dependencies BR Jérémy If you can suggest me a way, maybe with some example I will change my code. Best Regards Marek Normally services are given a certain amount of time to stop after SIGTERM (or whatever KillSignal was set, or whatever ExecStop command was specified). Even if microupsd doesn't handle SIGTERM nicely (which I'd call a bug), it's possible to add some... arbitrary delays. Units are stopped due to having automatic Conflicts=shutdown.target, if I remember correctly. I'm not sure if disabling that default dependency is a good approach though... This time I can't think of a good combination that'd solve both problems without introducing some ugly race conditions... On Tue, Aug 8, 2017, 21:46 Marek Floriańczyk <marek.florianc...@gmail.com> wrote: Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze: 08.08.2017 17:03, Marek Floriańczyk пишет: What would be the proper way to distinguish between system is going down for reboot and for shutdown ? Straightforward way is to make your service WantedBy poweroff.target and halt.target. You can then have second service WantedBy reboot.target and kexec.target. They may even call the same binary (script) but with different arguments. Thanks for answer, So, my binary "microupsd" is started by /etc/init.d/microups at the boot time to monitor power input, battery status etc. During system halt I need to send SIGUSR1 to this "microupsd" process at which it will send command to microups device, moreover I would like to give it some time (like 1-2 seconds) to accomplish the transmission. I don't need to send anything in case of reboot. Should I prepare some script that sends SIGUSR1 to "microupsd" process and then sleeps for 2 seconds and set it as WantedBy poweroff.target and halt.target ? How can I be sure that this script will be called before "microupsd" is actually killed during system shutdown ? Best Regards Marek ___ 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 -- Logo <http://www.smile.fr/> 20 rue des Jardins 92600 Asnières-sur-Seine www.smile.fr <http://www.smile.fr/> *Jérémy ROSEN* Architecte technique Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> Tel : +33141402967 Facebook <https://www.facebook.com/smileopensource> Google%2B <http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn <https://www.linkedin.com/company/smile> Twitter <https://twitter.com/GroupeSmile> bandeaux_mail <http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/default.target.wants/ no longer checked for unit files
On 16/07/2017 16:33, Lennart Poettering wrote: On Fri, 14.07.17 10:13, Richard W.M. Jones (rjo...@redhat.com) wrote: https://github.com/systemd/systemd/issues/6334 Since this commit https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119bbb4427244 (in v233 and v234), you can no longer create /etc/systemd/system/default.target.wants/ and drop in service files (or symlinks). The directory is skipped. I have reverted the commit on top of systemd from git and that makes defaults.target.wants work again. Is this supposed to work? It worked fine since at least Fedora 18-25, but it is now broken in Fedora 26. The new code in systemd is simply broken, and we really need to fix this. The old behaviour was correct. can I ask a more generic question ? How should alias and drop-in work ? for all intent and purpose, default.target is an alias for multi-user.target (or other) should alias drop-ins be loaded when we start an alias but not the main names ? should all drop-ins from all alias be used ? only the one for the one we call ? should we skip drop-ins for the main name ? afaik this is an interesting question that is not documented anywhere... Jérémy Lennart -- Logo <http://www.smile.fr/> 20 rue des Jardins 92600 Asnières-sur-Seine www.smile.fr <http://www.smile.fr/> *Jérémy ROSEN* Architecte technique Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> Tel : +33141402967 Facebook <https://www.facebook.com/smileopensource> Google%2B <http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn <https://www.linkedin.com/company/smile> Twitter <https://twitter.com/GroupeSmile> bandeaux_mail <http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] magically disappearing filesystems
I'm pretty it should only be necessary to call daemon-reload before using systemctl. It warns if any source files (unit files, dropins and anything mentioned by SourcePath= in a unit) have been updated since the last reload. The fstab generator should be using SourcePath=. Would it be theoretically possible to do a .path that looked at /etc/fstab and triggered a daemon-reload, or would that be a bad idea for reasons I don't imagine ? Jeremy - Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Logo <http://www.smile.fr/> 20 rue des Jardins 92600 Asnières-sur-Seine www.smile.fr <http://www.smile.fr/> *Jérémy ROSEN* Architecte technique Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> Tel : +33141402967 Facebook <https://www.facebook.com/smileopensource> Google%2B <http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn <https://www.linkedin.com/company/smile> Twitter <https://twitter.com/GroupeSmile> bandeaux_mail <http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logging API
The logging API provided by journald is already very rich, have a look at man:sd_journal_send if you just want log levels, do note that journald will parse lines starting with "<1>" and related prefix as syslog levels and correctly treat them... even if those messages arrive through the stdout of your daemon man:sd-daemon has the details of that particular feature. it's particularly easy to use. On 20/04/2017 09:41, Łukasz Stelmach wrote: Hello. I am writing a new piece of code. After several dozens of fprintf(3) calls here and there I decided to clean that mess. I really like the internal logging API (log_error(), log_debug(), log_info_errno() etc.) used by systemd parts. Is it possible to make it part of the public libsystemd API? Where to start the work? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Logo <http://www.smile.fr/> 20 rue des Jardins 92600 Asnières-sur-Seine www.smile.fr <http://www.smile.fr/> *Jérémy ROSEN* Architecte technique Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr> Tel : +33141402967 Facebook <https://www.facebook.com/smileopensource> Google%2B <http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn <https://www.linkedin.com/company/smile> Twitter <https://twitter.com/GroupeSmile> bandeaux_mail <http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature_medium=email_campaign=signature> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd reboot problem
Note that if you are calling from C code, you might want to call it
through the Dbus API, rather than the "system" system call.
As for debugging what blocks the shutdown, here are a few clues
* does "systemctl reboot -f" stop the system correctly ?
if yes, one of your daemons is blocking the shutdown, check all the
printed logs for a "Stopping " with no corresponding "Stoped XXX"
try stopping manually that service and debug what's going on with it
* does "systemctl reboot -f -f" stop shut down the system (this will not
unmount correctly the filesystems and is only for debugging purpose)
if that does not stop the system, your problem is at the
kernel/hardware level. More specifically, your kernel does not know how
to turn the power off on your system.
Jérémy
On 30/03/2017 10:47, Lennart Poettering wrote:
On Tue, 07.03.17 03:15, lin webber (webber...@outlook.com) wrote:
I use “system("reboot")” in my C program and system does not shutdown.I think
that systemd is waiting for some services to shutdown which can't shutdown immediately.
But I don't want to wait for those services to shutdown.How can I shutdown my
system immediately in my C program.which API should I call?
Thank you for reply.
There are several ways to reboot your system:
1) use the raw reboot() syscall. In this case file systems might end
up being dirty, and some more complex daemons might not like it
either.
2) Use "systemctl reboot -ff", which is pretty much the same as #1,
but accessible from the shell.
3) Use "systemctl reboot -f", which is a slightly friendlier version
than the above. In this mode, systemd won't bother with stopping
services correctly (instead it will just SIGTERM them all and
SIGKILL what is left then). However it will still place all file
systems in a clean state before issuing reboot().
4) Use "systemctl reboot", which is the friendliest version and
correctly shuts down all services, i.e. is equivalent to plain
"reboot" the way you already tried.
Unless you have a completely stateless system with all file systems
either read-only or formatted on each boot #3 is the vastly better
option than #1/#2.
Lennart
--
Logo <http://www.smile.fr/>
20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr <http://www.smile.fr/>
*Jérémy ROSEN*
Architecte technique
Email : jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
Tel : +33141402967
Facebook <https://www.facebook.com/smileopensource> Google%2B
<http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn
<https://www.linkedin.com/company/smile> Twitter
<https://twitter.com/GroupeSmile>
bandeaux_mail
<http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature_medium=email_campaign=signature>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
