Re: [systemd-devel] systemd user unit - how to prepare environment?
Lennart Poettering writes: [...] >> > >> > (i.e. I would to have PATH=$PATH:xxx) > > You can add them to ~/.config/systemd/user.conf in the Environment= > field in the [Manager] section, see systemd-system.conf(5).x Two questions: 1. Can I there use construct like PATH=$PATH:xxx? 2. whether there is a such file on user level? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html Trust in Allah, but tie your camel. -- Arabian proverb ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user unit - how to prepare environment?
Hi, > So my question is, where to init variables for user units? > I woluld like to have possiblity to set them as not only as fixed > strings > > (i.e. I would to have PATH=$PATH:xxx) You can add them to ~/.config/systemd/user.conf in the Environment= field in the [Manager] section, see systemd-system.conf(5).x How does this compare to man 5 environment.d ? -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging "A stop job is running" shutdown messages
You can run: journalctl -b-1 -r This will show the logs from the last boot (-b-1) in reverse (-r). You can then scroll down a bit and see what services didn't stop on time. In addition, during shutdown you can press Ctrl+Alt+Del 8 times within 2 seconds (much easier than it sounds) in order to force the system off. Side note: if you're using any Flatpak apps, I've noticed that flatpak-spawn can prevent the system from shutting down. On Tue, Sep 11, 2018, 2:19 PM Mantas Mikulėnas wrote: > On Tue, Sep 11, 2018 at 10:06 PM Evan Klitzke wrote: > >> When I power off my laptop, I often (but not always) have a long >> shutdown process. When this happens, the console says "A stop job is >> running for User Manager for UID 1000" with a 1m59s timeout, and I have >> to wait for that timeout before my computer shuts down. How can I debug >> which service is causing this issue? >> > > Have debug-shell.service running before poweroff. During the hang, switch > to tty9 and run: > > sudo -u evan XDG_RUNTIME_DIR=/run/user/1000 systemctl --user list-jobs > > -- > Mantas Mikulėnas > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging "A stop job is running" shutdown messages
On Tue, Sep 11, 2018 at 10:06 PM Evan Klitzke wrote: > When I power off my laptop, I often (but not always) have a long > shutdown process. When this happens, the console says "A stop job is > running for User Manager for UID 1000" with a 1m59s timeout, and I have > to wait for that timeout before my computer shuts down. How can I debug > which service is causing this issue? > Have debug-shell.service running before poweroff. During the hang, switch to tty9 and run: sudo -u evan XDG_RUNTIME_DIR=/run/user/1000 systemctl --user list-jobs -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Debugging "A stop job is running" shutdown messages
When I power off my laptop, I often (but not always) have a long shutdown process. When this happens, the console says "A stop job is running for User Manager for UID 1000" with a 1m59s timeout, and I have to wait for that timeout before my computer shuts down. How can I debug which service is causing this issue? -- Evan Klitzke pgp: 0x157EFCACBC648422 e: e...@eklitzke.org w: https://eklitzke.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount unit with special requirements
Hi, [...] >> No, I wrote: >> >> *- The partition has to be mounted on boot.* >Well, what does that mean? Do you just want the path to be available? >if so, that's what an automount unit will do for you without actually >mounting the superblock. Or do you want the superblock to be hooked in >already? If so, why? Why wouldn't the automount be good enough? to be honest, I never tried it, but I will - following your approach from the other mail. >> - It has to be unmounted before the nightly copy job, so that an fsck >> can be performed. >Well, but why would you do that. Why isn't it enough to run the fsck >once before the first mount after each time the device initially >appeared? I simply never used automount units, so I had no idea about their capabilities. >Lennart Bye. Michael. -- Michael Hirmke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user unit - how to prepare environment?
On Di, 11.09.18 09:26, Kamil Jońca (kjo...@o2.pl) wrote: > I post on debian-user, but no answer. > Maybe here I found some knowledge. > > KJ > kjo...@poczta.onet.pl (Kamil Jońca) writes: > > > I tried to setup some user units in my desktop, and have problem with > > env variables. > > So far I set them up in custom .xsession file (in home directory) > > I tried to put > > something like > > systemctl --user import-environment NNTPSERVER > > in my .xsession file, but it looks like this script is run parallel with > > user units, and I have race condition, ie. some units can't see > > variables. > > > > So my question is, where to init variables for user units? > > I woluld like to have possiblity to set them as not only as fixed > > strings > > > > (i.e. I would to have PATH=$PATH:xxx) You can add them to ~/.config/systemd/user.conf in the Environment= field in the [Manager] section, see systemd-system.conf(5).x Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Enforcing journald diskspace limit.
On Mo, 20.08.18 14:08, Frédéric HILPERT (frede...@hilpert.me) wrote: > Hi, > > I have a question about systemd. Not wanting to create an issue on githbub > because there are already plenty and this may not be a bug. > > I have a 1GB /var/log/ partition (on a stock Centos 7) and set > SystemMaxUse=150M in journald configuration. When I restart journald I have > this message : > > /systemd-journal[53564]: Permanent journal is using 8.0M (max allowed > 101.4M, trying to leave 152.1M free of 501.0M available → current limit > 101.4M).// > / > Everything looks fine here, but a few days later : > / > //MyServer# journalctl --disk-usage // > //Archived and active journals take up 232.8M on disk.// > //MyServer# du -sh /var/log/journal/// > //185M /var/log/journal// > > --> Am I missing something in order to enforce journal not use more than 150 > (or 101.4)MB ? Currently the journal vacuuming logic wil not remove active journals but only archived ones. This means that if you have many active journals (i.e. many different users logging as each user gets one) the limit may be hit anyway. you can decrease the size each journal can grow at max, with SystemMaxFileSize=. Note however that making this size too small also has drawbacks as journalctl coalesces all files it finds and interleaves them, of which the performance grows with O(n) with n being the number of files... Lennart -- Lennart Poettering, Red Hat ___ 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?
On Mi, 29.08.18 12:24, Wojtek Swiatek (w...@swtk.info) wrote: > 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)?* Ideally your distriution would solve this or help you with it. This is after all not a problem specific to portable services, but having a minimal system is useful in almost all cases. One idea is to use an initrd builder to put these images together. For example, in systemd's set of tests we have something based on the "dracut" initrd builder that puts together minimal testing images and runs them in qemu and nspawn (see test/TEST-*/ in the sources). something like this could also be used to put together portable services. initrd builders usually start with a minimal set of files you specify and then have limited logic built in to add necessary dependencies of these files (usually by following ELF .so deps and such). It certainly would be a cool project to maybe generalize and beef up the dracut image logic for building such portable service images! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] non-dev systemd-devel package for Linux
On Sa, 01.09.18 01:00, Reindl Harald (h.rei...@thelounge.net) wrote: > Am 31.08.18 um 23:41 schrieb Sayeed hyder: > > Thanks, I am not confused between udev and devel. Let me explain a bit > > more. My understanding is with the devel package, when I include in my > > project, I am downloading all the header files and redistributing the > > code. With the non-devel runtime package (e.g. libudev1 in Ubuntu), I > > can avoid that. Does that clarify my question and confusion? > > no, the devel package are for *compile* whatever > you really have no clue what you are talking about as nobody else has Reindl, please tone it down. Please be friendlier. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user unit - how to prepare environment?
On Tue, Sep 11, 2018 at 10:34 AM Kamil Jońca wrote: > I post on debian-user, but no answer. > Maybe here I found some knowledge. > > KJ > kjo...@poczta.onet.pl (Kamil Jońca) writes: > > > I tried to setup some user units in my desktop, and have problem with > > env variables. > > So far I set them up in custom .xsession file (in home directory) > > I tried to put > > something like > > systemctl --user import-environment NNTPSERVER > > in my .xsession file, but it looks like this script is run parallel with > > user units, and I have race condition, ie. some units can't see > > variables. > > > > So my question is, where to init variables for user units? > > I woluld like to have possiblity to set them as not only as fixed > > strings > > > > (i.e. I would to have PATH=$PATH:xxx) > > > > KJ > > Start your units after this is done. That is, don't link them to your default.target, but call `systemctl --user start foo.service bar.target quux.service` in the same .xsession file right after importing environment. (This has some advantages: it doesn't delay the whole login process as default.target would, and it allows you to start graphical apps as systemd units.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user unit - how to prepare environment?
I post on debian-user, but no answer. Maybe here I found some knowledge. KJ kjo...@poczta.onet.pl (Kamil Jońca) writes: > I tried to setup some user units in my desktop, and have problem with > env variables. > So far I set them up in custom .xsession file (in home directory) > I tried to put > something like > systemctl --user import-environment NNTPSERVER > in my .xsession file, but it looks like this script is run parallel with > user units, and I have race condition, ie. some units can't see > variables. > > So my question is, where to init variables for user units? > I woluld like to have possiblity to set them as not only as fixed > strings > > (i.e. I would to have PATH=$PATH:xxx) > > KJ -- http://wolnelektury.pl/wesprzyj/teraz/ Bolub's Fourth Law of Computerdom: Project teams detest weekly progress reporting because it so vividly manifests their lack of progress. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
