Re: [gentoo-user] Re: systemd - are we forced to switch?
Canek Peláez Valdés can...@gmail.com wrote: On Tue, Jul 23, 2013 at 2:04 AM, András Csányi sayusi.a...@sayusi.hu wrote: On 23 July 2013 08:54, Nikos Chantziaras rea...@gmail.com wrote: On 23/07/13 08:43, Samuli Suominen wrote: On 23/07/13 00:46, Mark David Dumlao wrote: This would be a lot less of an issue if someone just wrote a logind ebuild (wink wink) that provides consolekit like it was originally intended. not possible, logind since systemd = 205 requires systemd and won't work on openrc, upstart, and such as in, the idea of using logind outside of systemd is a dead end so keeping ConsoleKit in portage for long as it works for long as we need openrc for Linux based systems and when it no longer works, the contingency plan is to ship vendor based polkit files that possibly either restore 'plugdev' group or provide similar groups to ArchLinux like 'network', 'storage', 'power' to split up the old 'plugdev' Wouldn't it be better to switch to systemd instead? Is there a migration guide? According to google there is no any. (or I haven't spend enough time to search) You have the wiki: https://wiki.gentoo.org/wiki/Systemd I believe it covers the most important aspects of the migration. Also, it is so much easier now; we even have a stable version on systemd in the tree. Couldn't emerge systemd its blocked by udev -- did a google search, but found some very confusing posts to do with static-libs. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] [systemd vs consolekit] packagekit-base
On 25 July 2013 22:31, Canek Peláez Valdés can...@gmail.com wrote: On Thu, Jul 25, 2013 at 3:06 PM, András Csányi sayusi.a...@sayusi.hu wrote: Hi All, [snip] Unity is in the tree? Where? In the unity-gentoo overlay. At the moment the overlay packages are clashing the already unmasked gnome-3.8. It requires a little job to manage it. The ebuild for packagekit-base has a hard dependency on consolekit, without an option for systemd. This is because the last version of PackageKit in the tree is 0.7.4, which is more than a year older (was released in April 2012). If you use Unity, the DE by Canonical for Ubuntu, the last thing you want is systemd. Canonical/Ubuntu is pretty clear on the fact that they support Upstart, not systemd. I did not know that. Based on that gnome wants systemd and unity uses gnome stuff I thought that there is a strong relation between them. And lastly, why do you want/need PackageKit? It worked horribly with portage, last time I tried some years ago. Gnome wants that and I do not know why. Maybe I did not pay enough attention for the USE flag which pulls in it. It requires an action - just being agile for a moment not having the first coffee today. :S If you use GNOME you need to use systemd. Unity is a completely different beast (although it uses the same technologies behind the curtains), and systemd would be blocked by some Unity stuff, if I understand correctly. I switched back to consolekit to avoid the possible collisions. The first thing I want is the Unity system working properly. After that I'm going to ask the guys who manages the unity overlay about consolekit/systemd stuff. -- -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu -- http://facebook.com/andras.csanyi -- Trust in God and keep your gunpowder dry! - Cromwell
Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Sun, 2013-07-28 at 11:16 -0500, Canek Peláez Valdés wrote: On Sun, Jul 28, 2013 at 8:23 AM, Michael Hampicke m...@hadt.biz wrote: Am 28.07.2013 10:07, schrieb Stefan G. Weichinger: Am 28.07.2013 10:04, schrieb Canek Peláez Valdés: The only special thing I'm doing is to mask sys-apps/systemd-204, since 205 introduced the new cgroups management code (with systemd as the only writer of the cgroups hierarchy), and it seems to cause some minor problems with logind. Other than that, it works withouth a glitch: gnome-base/gnome-3.8.0, sys-apps/systemd-204, no consolekit at all. Same here, yes. I run systemd-206 but I didn't notice an problem(s) yet. Maybe there are some and I don't get it ;-) I had one problem, but I am not sure, if it's related to systemd 204, the removal of consolekit, or gnome at all. But when logging into my gnome session, /usr/libexec/gvfsd-fuse can not be started, because the permissions of /dev/fuse are rw-- root:root Other distros like ubuntu have a fuse group for that, which does not exist on gentoo. So I assume the default permissions for /dev/fuse on gentoo machines should be rw-rw-rw- root:root? My problem was that *sometimes* (not always) I was unable to unlock my session after suspending my laptop or desktop. Reverting back to systemd-204 solved it, so I'm assuming that's the problem, although I didn't really investigated the issue. This turned out to be an upstream issue. See: https://bugs.freedesktop.org/show_bug.cgi?id=67267 and the corresponding Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=477954 Upstream has already fixed it on git, so we'll either have to wait until systemd-207 or see if the systemd maintainers cherry pick the patch as 206-r1 on portage. --Mark
Re: [gentoo-user] gentoo-systemd-only deprecation
On Sunday 28 July 2013 03:22:02 Canek Peláez Valdés wrote: William Hubbs closed bug #409385[1] as fixed, introducing virtual/service-manager and adding it to the @system set, and dropping OpenRC from baselayout's post dependencies. Therefore, as of today, anyone can have a Gentoo machine with only systemd, with no OpenRC installed. Really? Bug 373219 is still open.
Re: [gentoo-user] gentoo-systemd-only deprecation
On Wed, 31 Jul 2013 07:34:22 -0400, Tanstaafl wrote: Where is this 'INSTALL_MASK' option for opting out of systemd completely documented? man make.conf -- Neil Bothwick If at first you don't succeed, redefine success. signature.asc Description: PGP signature
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Wed, Jul 31 2013, Graham Murray wrote: Canek Peláez Valdés can...@gmail.com writes: The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev, which you need to uninstall before installing systemd. Perhaps it's CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install the udev binary in different directories, so the script is basically useless after the switch. It is pulled in by sys-fs/udev-init-scripts which is a dependency of systemd[openrc]. So the Wiki is correct. But the wiki doesn't specify emerging system with the openrc flag. Should I suggest that the wiki be modified. To be sure I understand. At this point I would have already 1. merged systemd (perhaps with USE=openrc ... 2. set USE=systemd ... 3. updated with emerge --newuse --deep --verbose--ask @world * The wiki doesn't say --update; is that correct? I would *not* have 1. added init=/usr/lib/systemd/systemd to the kernel line in grub 2. rebooted. A related question. Am I correct in believing that once I do the emerge ... @world above I can *not* reboot until I have added the init=... phrase to the kernel line in grub (and thus committed to systemd not OpenRC) Thanks to all allan
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Wed, Jul 31, 2013 at 9:28 AM, gottl...@nyu.edu wrote: On Wed, Jul 31 2013, Graham Murray wrote: Canek Peláez Valdés can...@gmail.com writes: The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev, which you need to uninstall before installing systemd. Perhaps it's CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install the udev binary in different directories, so the script is basically useless after the switch. It is pulled in by sys-fs/udev-init-scripts which is a dependency of systemd[openrc]. So the Wiki is correct. But the wiki doesn't specify emerging system with the openrc flag. Should I suggest that the wiki be modified. To be sure I understand. At this point I would have already 1. merged systemd (perhaps with USE=openrc ... 2. set USE=systemd ... 3. updated with emerge --newuse --deep --verbose--ask @world * The wiki doesn't say --update; is that correct? I would *not* have 1. added init=/usr/lib/systemd/systemd to the kernel line in grub 2. rebooted. I think (now that Graham correctly pointed that you can preserve /etc/init.d/udev with the openrc USE flag), that then you should restart udev. A related question. Am I correct in believing that once I do the emerge ... @world above I can *not* reboot until I have added the init=... phrase to the kernel line in grub (and thus committed to systemd not OpenRC) That, I believe, is correct. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] gentoo-systemd-only deprecation
On 31 July 2013, at 20:09, Canek Peláez Valdés wrote: … if you used systemd, and tried to run /etc/init.d/whatever start, … Nowadays you get the following warning: * You are attempting to run an openrc service on a * system which openrc did not boot. *... So it's pretty harmless. Oh, nice. That's very acceptable, then - a clean migration path. Stroller.
[gentoo-user] how to tell you are using systemd?
Can a shell script tell if systemd is the init? I have a couple of places where it would be nice to know this. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] how to tell you are using systemd?
在 2013-8-1 上午10:26， cov...@ccs.covici.com写道： Can a shell script tell if systemd is the init? I have a couple of places where it would be nice to know this. Thanks in advance for any suggestions. Check /proc/1/comm or something like that, IIRC...
Re: [gentoo-user] Moving from old udev to eudev
On Fri, Aug 02, 2013 at 02:42:36AM +0300, Samuli Suominen wrote nope, you just believed all the FUD there has been out there. i've said it many times, and i'll say it again: the only real different is USE=rule-generator and that's it and sys-fs/eudev is constantly out of date and haven't developed any features of their own udev, the red-headed stepchild of systemd, hasn't exactly had a lot of new features, either. The following FUD brought to you by Lennart Poettering - Red Hat, Inc. http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html Well, we intent to continue to make it possible to run udevd outside of systemd. But that's about it. We will not polish that, or add new features to that or anything. OTOH we do polish behaviour of udev when used *within* systemd however, and that's our primary focus. And what we will certainly not do is compromise the uniform integration into systemd for some cosmetic improvements for non-systemd systems. Straight from the horse's mouth, udev won't be getting new features and the systemd maintainers' main target is integration into systemd. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Moving from old udev to eudev
On 04/08/13 05:56, Walter Dnes wrote: On Fri, Aug 02, 2013 at 05:02:39AM +0300, Samuli Suominen wrote Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. You want eudev removed, and Lennart Poettering wants udev on non-systemd systems dropped. Add those two items together, and we get systemd rammed down our throats... http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html (Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.) That might be the systemd upstream view point, but definately isn't mine. Fact is that udev can be built and ran standalone without systemd and you don't need eudev for that. If udev upstream makes it impossible to build, or run it standalone then we need to patch or fork it -- but that's far from now. In any case there will always be sys-fs/udev and it will never require sys-apps/systemd. Futhermore sys-fs/udev will be the default for long as sys-apps/openrc is the default. I mean, why the heck fork something too early when upstream still supports udev on non-systemd init systems?! - Samuli
Re: [gentoo-user] Re: Optional /usr merge in Gentoo
On 19/08/2013 19:03, Yohan Pereira wrote: On 19/08/13 at 09:36pm, William Kenworthy wrote: So why not a profile so those guys who want to play can get a configuration that better suits them? - and vice versa if the whole systemd push dies and Redhat drops it as I doubt anyone else big enough will pick it up (they have a foot in both camps at the moment). Smaller distros that jump entirely systemd will be in trouble until they move back. Not a systemd supporter in any way but I don't think making a profile makes sense because we already have profiles for kde, gnome, desktop etc. Users will probably want to use systemd in-conjunction with any one of those, so we would need to have kde-systemd, gnome-systemd .. which is absurd. At least I don't see a sane way to achieve it from my rudimentary understanding of profiles. The only way it could be done is to have additive profiles, i.e. a collection of possible profiles such as gnome, kde, openrc, systemd - pick all that apply. This very rapidly cascades into a total nightmare when one profile say to include thing X and another says to exclude thing X. There's no sane default handling for that, one has to install local policy that applies a precedence rule. USE=systemd is far better (ignoring for the moment the difficulties in actually switching the service manager over) -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] looking for a couple of systemd units
Hi. I am looking for a couple of systemd units which I have not been able to find -- one for mailman and one for innd which is a shell script by itself. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] looking for a couple of systemd units
While we are at it ... I am currently migrating one of my basement servers ... it boots and runs with systemd already. I am fiddling with service-files for: mysql mythbackend tftp-hpa (more to come) working my way through ... making arch-linux-files fit etc. If someone already has those for gentoo ... pls post and share! Stefan
[gentoo-user] digikam + systemd
I just did 'emerge -pv digikam' for 3.3.0 it wants to install 54 pkgs, incl systemd ; 10 pkgs are KDE include Marble. Is my surprise justified ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] systemd and kernel symbol HOTPLUG
On Thu, Sep 12 2013, gottl...@nyu.edu wrote: The premerge check for systemd complains that CONFIG_HOTPLUG is not set. grep .config does not show CONFIG_HOTPLUG make menuconfig when asked to search for HOTPLUG shows that is has the value HOTPLUG (?). It also asserts that HOTPLUG is selected by a Boolean combination of flags all of which are true (and none are negated). What gives? thanks, allan See bug #484602. allan
[gentoo-user] systemd and kernel symbol HOTPLUG
The premerge check for systemd complains that CONFIG_HOTPLUG is not set. grep .config does not show CONFIG_HOTPLUG make menuconfig when asked to search for HOTPLUG shows that is has the value HOTPLUG (?). It also asserts that HOTPLUG is selected by a Boolean combination of flags all of which are true (and none are negated). What gives? thanks, allan
Re: [gentoo-user] systemd and lvm
Am 12.09.2013 18:22, schrieb Canek Peláez Valdés: Really, whomever is recommending to set CONFIG_UEVENT_HELPER_PATH is probably wrong. I can't find *one* place where it is recommended, and several where they explicitly say to leave the option in blank. So ... I agree with this. What to do about the initial problem then? With openrc lvcreate is no problem, with systemd it is ... (for me, on 2 machines). Stefan
Re: [gentoo-user] systemd installation location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2013 02:52 PM, William Hubbs wrote: All, I can clarify one part of the systemd issue, because I have been involved in this part of the issue for months. Again, I am not trying to start a dispute here, just providing a clarification. The choice to install all of the systemd binaries in /usr is not an upstream choice. It was a choice made a year ago when our systemd team was one person [1], and now the team doesn't want to change it because it would require users to go through a migration, and the rest of the team doesn't see a benefit in changing it since it still links to libraries in /usr/lib. I joined the team, primarily to take responsibility for this change and to try to make it go as smoothly as possible, but I was overruled even though upstream gave us a pretty strong warning about it. William [1] http://blogs.gentoo.org/mgorny/2012/01/04/moving-systemd-into-usr-the-technical-side/ Ouch. So systemd upstream doesn't suggest putting binaries in /usr? That shows at least a little respect for /bin, et al. Based on the blog post, I'm getting the feeling that -- for systemd anyway -- the issues with /usr are caused by its dependencies rather than systemd itself. If dbus and whatnot were in /bin where they belong, the need for an initramfs (for separate /usr) and/or dealing with things in a non-standard place wouldn't need to happen. I'm not affected by anything regarding the /usr switch, but I'd like to have a good talk with the first person who decided a system-critical binary belonged in /usr instead of /bin or /sbin. They've created a mess for every distro and any project that depends on their work. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSSMu5AAoJEJUrb08JgYgHFz4H/iyZt6MlTeW702KOlIy2Ydse mzsfiyPfPz8Rbz0Mqp5/17R8aQzOUG4l6dZS7d9HFKuMCG7t+kNZCSvxD69XeTVO tZY6YjHCGQaE6WaAMbiasXfRTeRt4ZDtP5l/lCUsYcTCWN13PyIcHCb5rGNHnHqq J/OcSeF5EoS+G/uSAuzDVaQ5wa0Z0qkqVSqQGjJ5NUHYIA5ZrtYpMNDR+MkFYYAB 7I4JE5kDXRYoBSiLLDb7tI7F1nGogHXxzECmMYW4ZneU0AJwhUAK0kU+oTHY2Z9Q 8TcjpdaG1BH4gA2NT+i+ZJz4XNqkMPa2vbvhcfGFs9Dg7IwabiuunOzh0GQM1S4= =jgci -END PGP SIGNATURE-
[gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
On 09/29/2013 04:58 AM, Volker Armin Hemmann wrote: As much as I hate systemd My Alzheimer's prevents me from remembering your reasons for hating systemd. Would you *very* briefly refresh my memory, please?
Re: [gentoo-user] recent trouble with wicd and systemd (non-global ctrl_ifname)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/12/13 09:47, Canek Peláez Valdés wrote: On Wed, Dec 11, 2013 at 4:52 PM, gottl...@nyu.edu wrote: At home I use a wired connection so did notice the following problem until I traveled and tried to connect wirelessly. The problem must have started sometime within the past month. If I have wicd started by systemd, i.e. systemctl enable wicd The wired network is started fine but not the wireless. Instead, I see in the systemd journal wicd[290]: Failed to connect to non-global ctrl_ifname: wired error: No such file or directory wicd[290]: Failed to connect to non-global ctrl_ifname: wireless error: No such file or directory If I instead systemctl disable wicd, reboot, and then manually type wpa_supplicant -i wireless -c /etc/wpa_supplicant/wpa_supplicant.conf -B it works. Indeed after I have booted I can start wicd and cannot get the error above, but the actual behavior is not consistent. My system is ~amd64, profile gnome/systemd My wireless driver is from the package broadcom-sta (wl) I have never used wicd, so I can't say exactly what it's the problem; but I was under the impression that wicd is basically dead. Its last release was more than a year and a half ago. Regards. I don't use wicd (or systemd) either, but you could have a look at what the systemd unit is attempting to run (assuming it isn't one of it's special type of units). Systemd units are just plain-text files. Default unit location is /usr/lib/systemd/system (or you could try locate wicd.service and the parameter you're looking for is ExecStart. - -- wraeth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKqQX4ACgkQGYlqHeQRhkxoQQD+LRA3QJms/qBejtGeiFmiSceu Md0wF/WRmLy36zKPrcMA/jKB5WjGuaFmUq/gAOH5uuVNHIDgdkM/+EkXm5gpcmgA =JstS -END PGP SIGNATURE-
Re: [gentoo-user] cannot boot using systemd and initrd
Mike Gilbert flop...@gentoo.org wrote: On Mon, Jan 20, 2014 at 7:38 AM, cov...@ccs.covici.com wrote: Hi. I am having a problem booting using systemd and an initrd generated by genkernel. I get the message that says (may be slight paraphrase) that /dev/mapper/linux--files-64--root does not appear to be a valid /, try again. Now in the gentoo guide to systemd, I did what I think it wanted me to do and wrote in my lilo append line real_init=/usr/lib/systemd/systemd . Now looking at the linuxsrc in the initrd, /usr is not even mounted when it is looking for its init -- after all that fuss about /usr -- and it only seems to look in /sbin for its init and dies. How can I solve this problem -- I suppose I could copy systemd over, but that seems nasty to me and I would have to remember to update it every time systemd was updated! Any assistance on this would be appreciated. This is bug 479730. https://bugs.gentoo.org/show_bug.cgi?id=479730 One solution would be to switch to genkernel-next. I recommend the latest ~arch version. Another solution would be to use dracut. OK, thanks -- gentoo-next looks like a good solution -- I hope it will still work with openrc since until I am sure systemd will do what I need, I will use openrc and forget gnome exists. Thanks again. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Restart network interface with systemd
On Thu, Jan 23, 2014 at 6:56 PM, Mansour Al Akeel mansour.alak...@gmail.com wrote: Hello all, I installed gnome3 few weeks ago, and had to migrate to systemd. The network init scripts are working fine. But I am not sure how to restart a specific interface. For example in the past I used to do: /etc/init.d/net.eth0 restart The wlan0 starts through wpa_supplicant under openrc. I can not remember doing any modification to adopt to systemd. The wpa_supplicant is not running under systemd, but wlan0 is working: neptune ~ # systemctl status wpa_supplicant wpa_supplicant.service - WPA supplicant Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled) Active: inactive (dead) Jan 23 19:54:20 neptune systemd[1]: Collecting wpa_supplicant.service I think it's because of dhcpcd, but not sure. my question now, is how to stop wlan0 and start eth0 with systemd ?? Are you still using the unpredictable network interface names[1]? Are you using net.ifnames=0 in your kernel command line? Could you please post the whole output of systemctl --full --all? We need to know what services you have enabled. Regards. [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Restart network interface with systemd
Canek, Thank you. The output is attached. On Thu, Jan 23, 2014 at 8:10 PM, Canek Peláez Valdés can...@gmail.com wrote: On Thu, Jan 23, 2014 at 6:56 PM, Mansour Al Akeel mansour.alak...@gmail.com wrote: Hello all, I installed gnome3 few weeks ago, and had to migrate to systemd. The network init scripts are working fine. But I am not sure how to restart a specific interface. For example in the past I used to do: /etc/init.d/net.eth0 restart The wlan0 starts through wpa_supplicant under openrc. I can not remember doing any modification to adopt to systemd. The wpa_supplicant is not running under systemd, but wlan0 is working: neptune ~ # systemctl status wpa_supplicant wpa_supplicant.service - WPA supplicant Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled) Active: inactive (dead) Jan 23 19:54:20 neptune systemd[1]: Collecting wpa_supplicant.service I think it's because of dhcpcd, but not sure. my question now, is how to stop wlan0 and start eth0 with systemd ?? Are you still using the unpredictable network interface names[1]? Are you using net.ifnames=0 in your kernel command line? Could you please post the whole output of systemctl --full --all? We need to know what services you have enabled. Regards. [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México systemd.output Description: Binary data
Re: [gentoo-user] going from systemd to udev
On 02/04/2014 01:58 PM, Joseph wrote: Is it possible to go from systemd to udev? I don't like the way systemd works. I have a problem with mounting USB sick (it mounts as root:root) and I can not even change the permission. I am receiving Hylafax fax transmission reports (email) on all incoming faxes and now these emails are empty. It all start happening after switching to systemd :-( systemd and udev are part of the same project, so I believe what you meant was switching from systemd to OpenRC. I've not made such a switch, but if you remember the steps you took, you can generally just reverse them. That is, emerge openrc again, change the kernel line in GRUB to point to regular init instead of systemd's init, reboot, and things *should* fall into place. USB drives mounting as root sounds like a udev thing rather than a systemd thing, and switching to OpenRC for your init won't fix it afaik. For the devices that you need this behavior for, it might be worth looking into writing some udev rules. You can get a start by consulting `lsusb` output and Googling for 'udev rules' to get a wide variety of guides for writing udev rules. Despite the recent changes to udev by the systemd team, udev still functions mostly the same and most guides will be accurate. I hope this helps! ~Daniel
Re: [gentoo-user] going from systemd to udev
On 02/04/14 20:06, Canek Peláez Valdés wrote: On Tue, Feb 4, 2014 at 8:01 PM, Joseph syscon...@gmail.com wrote: On 02/04/14 19:33, Canek Peláez Valdés wrote: [snip] emerge -pv gnome-base/gvfs If you have the gdu USE flag enabled, I recommend switching to udisks. It's possible that it will fix everything, but I have never used Xfce, so I'm not certain. Do I need to put flag: systemd in make.conf file: USE=... to enable it globally? Supposedly, you should enable local flags per package in /etc/portage/package.use, but many does put it on make.conf. Either way, if you are using systemd, you *should* set the systemd USE flag on everything, otherwise the package in question will try to use the non-systemd implementation (if any), and that will (almost surely) fail under systemd. Regards. After enable systemd flag in make.conf USE= the following packages were rebuild: sys-apps/busybox sys-apps/dbus sys-auth/pambase sys-auth/polkit sys-fs/udisks sys-power/upower gnome-base/gvfs But now I have a BIG problem, I can not mount USB stick at all as user (only as root). Eject doesn't work either. Did you rebooted? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México Yes, I did. Should I reverse it? Remove flag systemd from make.conf and rebuild. -- Joseph
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html Also, for those of you who don't follow Linux-related news, Ubuntu will also change to systemd in the future: http://www.markshuttleworth.com/archives/1316 And I *heard* that Slackware was also discussing the possibility, but since I don't follow Slackware at all, I don't know for sure. Anyway, distros not using systemd, and that they are not really small and/or niche, seem to be disappearing. The discussion that Tanstaafl posted is interesting since the arguments used by the four TC members are really focused on the technical merits of the proposed init systems. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Saturday 15 Feb 2014 17:32:44 Canek Peláez Valdés wrote: On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html Also, for those of you who don't follow Linux-related news, Ubuntu will also change to systemd in the future: http://www.markshuttleworth.com/archives/1316 And I *heard* that Slackware was also discussing the possibility, but since I don't follow Slackware at all, I don't know for sure. Anyway, distros not using systemd, and that they are not really small and/or niche, seem to be disappearing. The discussion that Tanstaafl posted is interesting since the arguments used by the four TC members are really focused on the technical merits of the proposed init systems. There was a thread sometime last year mentioning a slimmer/slicker and obeying to the *nix design principles initialisation system, but can't find it at the moment. Isn't that at all in the running? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 17/02/14, Canek Peláez Valdés wrote: It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Interesting. Didn't know that. What packages need to be recompiled? BTW, respect for your patience in this thread! -- Nicolas Sebrecht
Re: [gentoo-user] systemd as a Profile - practical or not?
On Tuesday 18 February 2014 10:46 PM, Yohan Pereira wrote: Burst out laughing reading this mail after reading this thread and the other systemd one. Anyways you'll find instructions here http://www.gentoo.org/main/en/lists.xml. Don't you like jokers? ;-) No offense, but RTFM!
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) That's the best response I've read in, like, many years. That's perfect; I'm 100% behind it. I even volunteer to help (with testing) to anyone going for this. You guys create a systemd-sucks-we-dont-want-it profile, and I promise to give you guys a hand. Make a profile that frees users from using systemd, and I think even several Gentoo developers will get behind that. Now we are talking; this has been my whole point the whole time. Everybody that don't want to use systemd; help this idea, and if there are enough of you, you'll pulled through. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Mark David Dumlao wrote: If udev wants systemd, and you don't, but you want to continue using udev, it's _your_ job to look for a method or patch or package or script that makes it work. That's already done. It's called eudev. :-D Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: banshee installation without systemd
On Sun, Feb 23, 2014 at 7:31 PM, eroen er...@falcon.eroen.eu wrote: On Sun, 23 Feb 2014 18:02:01 +0100, Fox halfsocial...@gmail.com wrote: Hello, after reading the thread about systemd somebody mentioned sys-fs/eudev. I decided used because I had systemd only to used udev and unmerge systemd. Now I can't use Banshee which I use as my music player because of the next dependency tree: banshee - gnome-base/gnome-settings-daemon - sys-apps/gentoo-systemd-integration - sys-apps/systemd and systemd can't be used because it conflicts with eudev. Is there anyway to avoid emerge systemd in this case? Thank you, Quim On a system running ~amd64 with eudev/openrc: eroen@falcon ~ $ emerge -pv media-sound/banshee =gnome-base/gnome-settings-daemon-2.32.1-r2 [ snip emerge output ] For ease of upgrades, you might want to add =gnome-base/gnome-settings-daemon-3 in /etc/portage/package.mask rather than specifying it with a specific version on the command line. That solution is a dead end. GNOME 2 is being removed from the tree[1]. Regards. [1] http://blogs.gentoo.org/eva/2014/02/16/the-future-of-gnome-2/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] Re: banshee installation without systemd
On Sun, 23 Feb 2014 19:47:55 -0600, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Feb 23, 2014 at 7:31 PM, eroen er...@falcon.eroen.eu wrote: On Sun, 23 Feb 2014 18:02:01 +0100, Fox halfsocial...@gmail.com wrote: Hello, after reading the thread about systemd somebody mentioned sys-fs/eudev. I decided used because I had systemd only to used udev and unmerge systemd. Now I can't use Banshee which I use as my music player because of the next dependency tree: banshee - gnome-base/gnome-settings-daemon - sys-apps/gentoo-systemd-integration - sys-apps/systemd and systemd can't be used because it conflicts with eudev. Is there anyway to avoid emerge systemd in this case? Thank you, Quim On a system running ~amd64 with eudev/openrc: eroen@falcon ~ $ emerge -pv media-sound/banshee =gnome-base/gnome-settings-daemon-2.32.1-r2 [ snip emerge output ] For ease of upgrades, you might want to add =gnome-base/gnome-settings-daemon-3 in /etc/portage/package.mask rather than specifying it with a specific version on the command line. That solution is a dead end. GNOME 2 is being removed from the tree[1]. Regards. [1] http://blogs.gentoo.org/eva/2014/02/16/the-future-of-gnome-2/ You probably mean temporary. The expression dead end would imply it makes future migration more difficult in some way. One would hope (mostly for their image's sake) the gnome team does not remove gnome-settings-daemon-2 until at least one of cinnamon-settings-daemon and mate-settings-daemon are included in gentoo proper. -- eroen signature.asc Description: PGP signature
Re: [gentoo-user] technical review of systemd
On Mon, Feb 24, 2014 at 3:09 AM, thegeezer thegee...@thegeezer.net wrote: [snip] using openrc if i reboot a system that requires fsck on /mnt/data it will do an fsck. but not log anything anywhere about the result, which is why i put this as a pro. Oh, I see; I hadn't understood this. does systemd have configurable options for '/' so that it can run readonly rather than dropping to emergency in case of problems? I believe you can run systemd out-of-the-box with / being RO. That's why /run and /run/lock are tmpfs' and they are available basically from the very beginning, and the reason /etc/mtab is a link to /proc/self/mounts. You need /var and some other stuff RW, if you want permanent logs and stuff, though. [snip] can you please clarify what you mean by absorbing iproute2? I don't use iproute2, so I don't know how big or complex it is; but if it's small and simple, it could just be absorbed in the systemd repo, like hwclock was [1]. *This is only speculation from my part*. I don't know how networkd would evolve in the future; perhaps it will always remain a little tool for trivial configurations only. And even if it evolves to cover every possible configuration on Earth, they will go with a different route from iproute2. [snip] the only reason that i bring this up is because if you _don't_ use systemd then /tmp is a folder hanging off / if you _do_ use systemd it will try to mount it tmpfs not everyone will realise this which is why i listed it as a 'gotcha' -- a nuance in working with it but not a major issue. OK, thanks for the clarification. [ snip ] thanks for the clearing up No prob. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/hwclock.c -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: technical review of systemd
On Feb 25, 2014 10:40 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Feb 25, 2014 at 5:38 AM, Nicolas Sebrecht nsebre...@piing.fr wrote: [snip] The way systemd services handle network whatever network manager you enable is the last thing preventing me from using systemd on servers. Seting up manual advanced setups on systemd looks crappy (if even possible with the provided tools) compared to OpenRC. Notice that iproute2 is the default everywhere for long time, here. The OpenRC comprehensive configuration set for network management is actually what I would expect in systemd. Perhaps they are starting small? I don't know; from what I've read, they want something small for simple cases, and if you need more you can use NetworkManager, connman, iproute2, or whatever. But then you had to configure it yourself. [snip] And, by the way, someone make me notice that netctl is an Arch'ism, and that the command-line front-end for networkd is actually networkctl. Yes, it was taken from Arch in order to allow better network support for advanced configurations whitout requiring to write yet another tool. Nothing was taken from Arch, I believe. networkctl and netctl had nothing to do with each other. The thing is that I would expect systemd to handle the whole thing on its own (with the help of iproute2) so that services have nice grain-level dependencies. If someone writes support for this and convinces the systemd maintainers that is a good idea, I think they would accept the patches. BTW, here is an overview of networkd by its author: https://coreos.com/blog/intro-to-systemd-networkd/ Regards.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Fri, 21 Feb 2014 17:33:43 + thegeezer thegee...@thegeezer.net wrote: Personally i'm most likely to stay with openRC, because the switch is non-trivial and have no faith in the xinetd-style socket arbitrator. It should be trivial, it is here. but would eselect be able to script the following: .. new kernel coptions Most of which you have already; beyond that, it's some minor functionality that doesn't stop the switch itself from working afaik. Only needs to be done once, not every time. .. new grub2 command line A new entry with init=/usr/lib/systemd/system suffices and doesn't need to be switchable; unless you want one entry and switch at runtime, alternatively it is possible to emerge sys-apps/systemd-sysv-utils, or simply change the symlink of /sbin/init and similar files yourself. .. install dbus (use=-systemd) _then_ systemd Only needs to be done once, not every time. .. would be nice to use an import for localed and hostnamed and timedated .. importing openrc services and runlevels to targets Would be nice to have. Only needs to be done once, not every time. .. pamd logind entires Only needs to be done once, not every time. .. syslogd changes to accomodate systemd Is this necessary? I don't remember doing this. .. setting systemd to log to syslog to make transitions smoother (as logs are lost on reboot by default) If this were to be done, this could be done in the systemd package. Out of all what is mentioned; you either need two GRUB entries or a single symlink that eselect controls, other than that there's nothing here to be made as part of eselect. Some of these things already are made the way they are by default, other things can happen as part of emerging a package; the other first install things are documented. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
[gentoo-user] converting openrc's dmesg to systemd service file
I'm sure this is way more trivial than I'm making it out to be, but how in the world would one converty /etc/init.d/dmesg to a systemd service file? Is there a good online pointer about building service files? -- Douglas J Hunley (doug.hun...@gmail.com) Twitter: @hunleyd Web: douglasjhunley.com G+: http://google.com/+DouglasHunley
Re: [gentoo-user] problems getting systemd to work
Am 15.05.2014 22:38, schrieb cov...@ccs.covici.com: image=/boot/vmlinuz-3.6.2-gentoo phew. 3.6.2 is from October 2012 ... Did you recompile it with the suggested options for systemd? Maybe it doesn't matter, but just a thought ... that kernel is quite old. Stefan
RE: [gentoo-user] Can't Get Systemd to Work
-Original Message- From: Stefan G. Weichinger [mailto:li...@xunil.at] Sent: Friday, May 16, 2014 9:40 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Can't Get Systemd to Work Am 16.05.2014 15:33, schrieb Hunter Jozwiak: -Original Message- From: Neil Bothwick [mailto:n...@digimed.co.uk] Sent: Friday, May 16, 2014 8:06 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Can't Get Systemd to Work On Fri, 16 May 2014 07:34:16 -0400, Hunter Jozwiak wrote: Hi all. I am having issues with Systemd as well. I added to the GRUB2 configuration file the needed command line to get Systemd to start, but for whatever reason, the kernel is adamant that I must use OrenRC. You need to tell us what you added and what the kernel complained about. The only information we have is what is in your mail, we are not the NSA, we cannot see what is on your computer. I recompiled with Genkernel-next a new kernel and initramfs, and that, for whatever reason, doesn't automount my /boot partition. Is there a fix to this? It is standard practice to not mount the /boot partition. By the time the boot process gets to mounting what is in /etc/fstab, /boot is no longer needed. That's why it is usually set to noauto in fstab. -- Neil Bothwick Guns don't kill people--it's those little pieces of lead. GRUB_CMD_LINE_LINUX=init=/usr/lib/system/system, rather. where is the quote, where is the text? And it's called systemd with a d - GRUB_CMD_LINE_LINUX=init=/usr/lib/system/systemd btw Changed the line to mirror that in the Grub file, no luck. #Append parameters to the Linux Kernel. GRUB_CMD_LINE_LINUX=init=/usr/lib/system/systemd Save the file. Mount /dev/sda2 /boot grub2-mkconfig -o /boot/grub/grub.cfg
Re: [gentoo-user] Systemd upower
On Wed, Jun 4, 2014 at 8:21 AM, Tanstaafl tansta...@libertytrek.org wrote: And yes, as devs get lazier (decide to rely on systemd rather than build it to work independently of the init system), this will in fact result in *users* (read: those lacking the skills to code every program out there to work without systemd) eventually being *forced* to switch to systemd. That is simply the reality. You can ignore it if you like, but it doesn't change it. Forced is forced. Well, if your goal is to persuade people to change, I'd suggest taking that to the upower mailing list, since they're the ones who added the systemd requirement. All anybody at Gentoo did was fork it and provide an alternative. The fiasco was the result of it being unclear that the option existed. However, the general trend I've seen is that when people complain to upstreams that they don't want them to depend on systemd, upstream tends to tell them to go make their own upstream. So, instead they complain on lists that don't ban them, like this one. It doesn't really fix anything though - it just gets everybody upset and often results in misdirected anger. The only thing Samuli did was give non-systemd users a workaround for an upstream problem, and the news clarifying this came out a bit late. I generally intend to switch over to systemd, but I for one would love for there to be the option to use alternatives. Simply wishing that won't make it happen, and since i don't really intend to use the alternatives it is a bit hard to get the motivation to help fork the world. That's just the way the wind seems to be blowing these days. Rich
Re: [gentoo-user] Re: N failed logins since your last login
#cat /etc/systemd/system/sklogd.service [Unit] Description=The syslogd half of sysklogd [Service] Type=forking EnvironmentFile=/etc/init.d/sysklogd ExecStart=/usr/sbin/syslogd -m 0 [Install] WantedBy=multi-user.target Did you play with log-level and log-level ? see http://www.freedesktop.org/software/systemd/man/systemd.html
Re: [gentoo-user] udev upgrade 208 212-r1, openrc USE flag changed to disabled?
On Sat, Jun 14, 2014 at 11:32 PM, Tanstaafl tansta...@libertytrek.org wrote: On 6/14/2014 2:15 PM, Tom H tomh0...@gmail.com wrote: On Sat, Jun 14, 2014 at 1:28 PM, Tanstaafl tansta...@libertytrek.org wrote: On 6/14/2014 1:02 PM, Mike Gilbert flop...@gentoo.org wrote: On Sat, Jun 14, 2014 at 10:31 AM, Tanstaafl tansta...@libertytrek.org wrote: *Why* was it removed/no longer needed? And why was it needed previously? Read the ChangeLog for sys-fs/udev, specifically the entry on 03 Apr 2014. Thanks - a half hour of googling didn't find this. 03 Apr 2014; Samuli Suominen ssuomi...@gentoo.org udev-212-r1.ebuild, udev-.ebuild: Punt USE=openrc and always pull in sys-fs/udev-init-scripts to match behavior of sys-apps/systemd's ebuild. Which means... what exactly? The only way I can make sense of your reply is... It means the only purpose of the openrc USE flag prio to this change was to pull in udev-init-scripts? See what I mean? How am I supposed to know that? It means that openrc users should strongly consider migrate to eudev. I use eudev since its beta and never had any issue, nor systemd leaking into my system. And in addition add the following at make.conf, as it seems that we are enforced to have files we never use. INSTALL_MASK=/lib/systemd /lib32/systemd /lib64/systemd /usr/lib/systemd /usr/lib32/systemd /usr/lib64/systemd /etc/systemd
Re: [gentoo-user] Re: ssh rekeying slow ?
Am 26.06.2014 00:20, schrieb Stefan G. Weichinger: pam_systemd is (or seems to be) the reason, see my other posting. maybe it would be also solved by upgrading to the (in terms of gentoo) unstable version 214 of systemd: # equery b pam_systemd.so * Searching for pam_systemd.so ... sys-apps/systemd-212-r5 (/lib64/security/pam_systemd.so) I will check tomorrow or so, late here. Stefan
[gentoo-user] systemd warning kernel 3.10 required
What is the significance of the warning when updating to systemd-214 that kernel 3.10 is required? I can't go to that now, what might break? Thanks. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Compiling for different CPU but same architecture
On Fri, 2014-08-01 at 13:55 +0530, Nilesh Govindrajan wrote: I wouldn't have taken interest in that one if I didn't have systemd. I'm using GNOME3 on both my desktop and the laptop, so systemd is a must. Yes, well, I thought it prudent just to make sure ;) -- wraeth wra...@wraeth.id.au signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] What to put in chroot mtab
On Fri, Aug 1, 2014 at 10:21 AM, Peter Humphrey pe...@prh.myzen.co.uk wrote: On Friday 01 August 2014 10:00:40 Canek Peláez Valdés wrote: ... just for completeness, systemd actually requires /etc/mtab as a link to /proc/self/mounts, so don't be surprised if software in the future in Linux just assumes that. Well, that seems to imply that you can't run a systemd chroot on a systemd or openrc host, no? If you want to boot a container with systemd-nspawn, then no, you can't; you need mtab to be a symlink to /proc/self/mounts. If you simply want to chroot to it, it doesn't matter; you will not be running systemd anyway. Because from inside the chroot, what /proc/self/mounts lists is inaccurate. In what sense is inaccurate? Inside my systemd-nspawn container: root@gentoo ~ # sort /etc/mtab | uniq /run /var/run none rw,bind 0 0 debugfs /sys/kernel/debug debugfs rw 0 0 fusectl /sys/fs/fuse/connections fusectl rw 0 0 hugetlbfs /dev/hugepages hugetlbfs rw 0 0 mqueue /dev/mqueue mqueue rw 0 0 tmpfs /tmp tmpfs rw,strictatime,mode=1777 0 0 That seems accurate to me. Sure, as Rich mentioned, there are repetitions and other stuff, but nothing that a quick grep or sort will not fix. I wouldn't like to be the one who has to write a new installation handbook for systemd-only systems! :) We'll need to rewrote the whole thing when we switch to systemd anyway. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] What to put in chroot mtab
On Friday 01 August 2014 10:29:17 Canek Peláez Valdés wrote: On Fri, Aug 1, 2014 at 10:21 AM, Peter Humphrey pe...@prh.myzen.co.uk wrote: On Friday 01 August 2014 10:00:40 Canek Peláez Valdés wrote: ... just for completeness, systemd actually requires /etc/mtab as a link to /proc/self/mounts, so don't be surprised if software in the future in Linux just assumes that. Well, that seems to imply that you can't run a systemd chroot on a systemd or openrc host, no? If you want to boot a container with systemd-nspawn, then no, you can't; you need mtab to be a symlink to /proc/self/mounts. If you simply want to chroot to it, it doesn't matter; you will not be running systemd anyway. Because from inside the chroot, what /proc/self/mounts lists is inaccurate. In what sense is inaccurate? Inside my systemd-nspawn container: root@gentoo ~ # sort /etc/mtab | uniq /run /var/run none rw,bind 0 0 debugfs /sys/kernel/debug debugfs rw 0 0 fusectl /sys/fs/fuse/connections fusectl rw 0 0 hugetlbfs /dev/hugepages hugetlbfs rw 0 0 mqueue /dev/mqueue mqueue rw 0 0 tmpfs /tmp tmpfs rw,strictatime,mode=1777 0 0 That seems accurate to me. Sure, as Rich mentioned, there are repetitions and other stuff, but nothing that a quick grep or sort will not fix. I only meant that things mounted outside the chroot are listed inside it, even though they can't be accessed from there. I've solved the problem for myself anyway, for now, by constructing a suitable mtab by hand from outside the chroot for use within it. I wouldn't like to be the one who has to write a new installation handbook for systemd-only systems! :) We'll need to rewrote the whole thing when we switch to systemd anyway. Indeed. -- Regards Peter
[gentoo-user] sysV/openrc init script vs. systemd .service file
I maintain some out-of-tree Linux device drivers that have been around for yonks and ship with system V init scripts. There's an install script (or Makefile recipe) that attempts attempts to figure out where to put an init script and set up symlinks as appropriate. It's not perfect, but so far it has worked good enough. It doesn't work great with openrc [e.g. doesn't enable the init script automatically], but people seem to be able to figure it out. Now I've got a customer that runs systemd and reports that the init script doesn't work for some undefined value of doesn't work. I've pretty much always been a system V init guy and have only grumblingly adapted to openrc. [Insert crotchety old Unix guy ramblings here... blah blah version 7... PDP-11 blah DECwriter blah silent 700 blah blah ASR-33... kids these days... ad naseam.] Needless to say: I find systemd distasteful, but I've got customers who use it. So... I keep reading that systemd is compatible with system V init scripts, but documentation on how that works seems to be somewhat lacking and/or wrong. e.g. The upstream docs refer to using /sbin/system to run old-style init scripts found in /etc/init.d, but neither /sbin/system nor the /etc/init.d directory seem to exsit on the systemd machine that I'm testing with. I'm currently testing with Arch Linux, but I'm also going to set up a Gentoo/systemd system. I've also seen recommendations that one would be better off just doing it the right way and writing a systemd .service file. Any advice on whether it would be easier to use a common init script with sysV/OpenRC/systemd or to write a separate .service file? -- Grant Edwards grant.b.edwardsYow! Where's the Coke at machine? Tell me a joke!! gmail.com
[gentoo-user] Re: [OT] Linus Torvalds on systemd
On 2014-09-18, Alec Ten Harmsel a...@alectenharmsel.com wrote: Mark David Dumlao wrote: The code is out there. Freely available. Both systemd and sysvinit. If you wanted to measure both, you could, literally, in the time it took since you first posted in this thread till now you could have measured several times and left mean comments about whichever system you hated the most. Unfortunately, the systemd guys keep screaming that systemd is faster, and burden of proof is on the party that's claiming something. It's not James'/Volker's responsibility to prove that systemd isn't faster. I don't understand all the hoopla about systemd being faster. Faster at what? Booting? The only Linux systems where I care about boot time are embedded systems which are never going to have the resources needed to run systemd. As for normal desktop machines, who cares? I only reboot them once every month or two (when I'm bored and want to make sure they will still boot up after updates). My laptop(s) get booted a lot more often than desktops, but the boot times have never been an issue. The other thing I keep hearing from systemd proponents is stuff about how it allows you to parallelize startup. I don't _want_ stuff starting up in parallel -- that just makes it all the more difficult to troubleshoot problems. I want things to start up one at a time, in a determined order. -- Grant Edwards grant.b.edwardsYow! The FALAFEL SANDWICH at lands on my HEAD and I gmail.combecome a VEGETARIAN ...
Re: [gentoo-user] Re: gigabyte mobo latency
On Sun, Oct 19, 2014 at 12:41 PM, James wirel...@tampabay.rr.com wrote: Even if we all end up migrating to systemd (which from plentiful complaints from many very bright folks about the net and the lack of a clean, useful documentation on systemd, it's likely to be a decade before systemd stablizes and folks produce sufficiently useful documentation and examples) cgroups does illuminate how things should work in a complex environment so it still is worth it's weight in gold, before one attempts to master the (systemd) beast. So, I realize there are many strong opinions regarding systemd, but this comes across a bit like, one should be well-accustomed to building and operating a Linux-From-Scratch installation before one attempts to master the (Ubuntu) beast. Sure, all that auto-magic stuff does add complexity, but it does so with the goal of standardizing and automating this so that you can use the system without having to worry about all the details. If you are running a systemd service you can set the various cgroup controls like IO and CPU class/priority in the unit and it will take care of managing the cgroup for you. Certainly learning the nuts and bolts of how it all works is worthwhile - I wouldn't be running Gentoo if I felt otherwise. However, you really don't have to know how to build your own service manager to use one. As far as docs go - what specifically is unclear? Systemd is rapidly evolving so things do get out of date, but for the most part stuff like this can be found in man systemd.exec and such. Lennart's series of blog posts on system administration using systemd is a very good place to start. -- Rich
Re: [gentoo-user] syslog-ng-3.6.1 nearly no log anymore
On Sat, Nov 15, 2014 at 04:11:56PM -0500, Rich Freeman wrote USE=systemd simply means to enable support for systemd, not that it is running. Generally stuff like this should be a matter of configuration, not build options. Otherwise your life as a Gentoo user would be a living nightmare when you look at how many profile use flags there are. There are already some situations where 2 programs cannot co-exist, e.g. 2 MTAs. This may be a similar situation in principle. A system daemon may operate differently under openrc than systemd. When I run emerge -pv syslog-ng I see that a systemd USE flag exists, but not an openrc USE flag. I think that's the root of the problem. The default is to support openrc. When the ebuild sees sees the systemd, it assumes you're not running openrc. Maybe the solution for syslog-ng is to add an openrc USE flag. Build in support for whichever flag is set. When experimenting, people might want to set both openrc and systemd USE flags for syslog-ng. If systemd users have to set the systemd flag for some ebuilds, I have no objection to setting the openrc USE flag in make.conf. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Does systemd work with mdadm?
On Fri, Nov 28, 2014 at 4:15 PM, Daniel Frey djqf...@gmail.com wrote: OK, I decided I'm going to try systemd to see what all the hubbub is about. I know there are people on here that use it so I'm hoping someone's can alleviate my concerns on it with mdadm. I use an IMSM container (Intel fakeraid) as I dual boot with Windows. This has happily worked for some time now. I've googled around and it seems there could be a bug using mdadm and lvm at the same time, but that's not what I'm doing. Considering when I first set up this dual boot there was some configuration involved, I don't believe I can just install it and pray it works as I've read if systemd goes sideways you can't even log in. Are there people running systemd and mdadm together that can comment? I think I'm going to try anyway, and I have a suspicion that systemd is going to bomb the first time it boots. Dan mdadm works perfectly fine with systemd. I am running a 4-disk RAID-10 configuration and it gets assembled properly by systemd. I have the ARRAY ... definition in /etc/mdadm.conf and the /dev/mdXXX mount point in /etc/fstab and AFAICT that's all you need, the default udev/systemd configuration brings it all up as expected. --Mark
[gentoo-user] Debian forked, because of systemd brouhaha
So, I just found out that some Debian Developers decided to fork Debian, because they can no longer stand this abomination called 'systemd': https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html What do you think, people? Shouldn't we offer them our eudev project to assist? Rgds, --
Re: [gentoo-user] Openrc now on Arch LInux
On Wed, Jan 21, 2015 at 5:32 PM, James wirel...@tampabay.rr.com wrote: Anyone tested openrc on Arch linux? I have read in several places that Arch linux has moved to systemd, exclusively? Don't believe everything you read. You'll probably also read that Gentoo doesn't use systemd. :) -- Rich
[gentoo-user] Re: Openrc now on Arch LInux
Rich Freeman rich0 at gentoo.org writes: Anyone tested openrc on Arch linux? I have read in several places that Arch linux has moved to systemd, exclusively? Don't believe everything you read. You'll probably also read that Gentoo doesn't use systemd. :) https://wiki.archlinux.org/index.php/OpenRC James
Re: [gentoo-user] Re: Get off my lawn?
Am 22.01.2015 um 19:06 schrieb Tom H: Sure. My point was that anyone can claim that systemd is (un)popular in the embedded space. I don't know if it is popular; in embedded systems though the last thing you need are fast moving targets IMHO, you want to use proven, reliable tools. If systemd is reliable or not, this depends on your decision, but it is a fast moving target.
[gentoo-user] systemd net interfaces always want a default route?
It looks like /etc/systemd/system/network@.service requires a gateway= line, however, for a second interface I wont set another default. Is there a standard way to so this, or do i have to copy network@.service to a new name and remove the 'ip route add' line?
Re: [gentoo-user] openrc-systemd command comparison
I've not seen any that are OpenRC specific... But this one is pretty decent for SysVInit vs. systemd... http://linoxide.com/linux-command/systemd-vs-sysvinit-cheatsheet/ On 17 March 2015 at 01:58, Canek Peláez Valdés can...@gmail.com wrote: On Mon, Mar 16, 2015 at 7:47 PM, Daniel Frey djqf...@gmail.com wrote: Hey all, I've now converted two systems to systemd and so far haven't had too much issues with systemd itself, other than me constantly forgetting commands. Is there a nice table or chart somewhere that lists openrc commands with equivalent systemd commands? That would really help me from bashing my head and then wandering through man pages for a while trying to figure out what I want to do. I'll eventually remember but it would be nice to have something to help me along. My memory sure isn't what it used to be. I remember seeing a table like that in the wiki a long time ago, but I can't find it now. Anyway, the translatable commands are obvious: /etc/init.d/service start → systemctl start service /etc/init.d/service stop → systemctl stop service and the rest are usually are not translatable. There is nothing like systemctl mask service in OpenRC, AFAIK, and there is no equivalent for /etc/init.d/service zap in systemd (the whole idea of systemd is that an ugly hack like zap will never be necessary). Not sure if this will help you. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México -- All the best, Robert
Re: [gentoo-user] installing gentoo with a systemd profile
On Sun, Jul 19 2015, Neil Bothwick wrote: On Sat, 18 Jul 2015 21:00:54 -0400, gottl...@nyu.edu wrote: I am installing gentoo on a new laptop. I am a gnome, hence systemd, user. I also use lvm (I have / and /usr combined on a non-lvm partition). At the point where you choose a profile (//wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Choosing_the_right_profile) I selected [5] default/linux/amd64/13.0/desktop/gnome/systemd * But now I get merge conflicts since I have sys-fs/udev installed. I can't depclean udev. Did you read this part? https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Optional:_Using_systemd Yes I did and had the systemd wiki page on a chromium tab while installing. It's been some months since I last did this, but I don't recall any serious conflicts. Why not just unmerge udev to avoid the blockage? I tried via depclean. I wanted to ask here before actually trying --unmerge, which seems rather brutal. I actually had a tiny part in the systemd wiki and remember that you could switch from an openrc system to systemd without unmerging. Instead, you either changed use flags (+systemd and -consolekit) or went to the a systemd profile (recommended). allan
Re: [gentoo-user] systemd very slow to compile?
On Sun, 13 Sep 2015 13:16:29 +0200, Marc Joliet wrote: > On Friday 11 September 2015 15:08:54 walt wrote: > >My very old and slow ~amd64 machine took 3 hours and 45-minutes to > >compile systemd-226 today. > > Just out of curiosity: exactly how old? My dual-core amd64 system is > almost 9 years old now, and systemd compiles in about 6 minutes: > > # genlop -t systemd > * sys-apps/systemd > Mon Sep 7 23:57:50 2015 >>> sys-apps/systemd-218-r3 >merge time: 12 minutes and 30 seconds. > > (My system might have been pretty busy on that last one, and the second > one must have been a binpkg merge.) > Perhaps it is a problem only in the build system of newer systemd > versions? It appears to have only occurred with systemd-226, which is why you are not seeing it. I won't post my emerge times because portage was building Chromium at the same time, but even so they were hours in excess of previous builds. -- Neil Bothwick "There's more to life than sex, beer and computers. Not a lot more admittedly..." pgp7KqN1aXes9.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Safe systemd "reload" command
On 06/04/2016 08:47 PM, Michael Orlitzky wrote: > > Sounds good, do you want to try it and add it to the wiki? =) > I just made an attempt and added it to the wiki: https://wiki.gentoo.org/wiki/SpamAssassin#Daily_updates It doesn't have any affect on my openrc system (good), but I would still appreciate it if someone with systemd can tell me that it works.
Re: [gentoo-user] Safe systemd "reload" command
On Tue, Jun 7, 2016 at 12:59 AM, Michael Orlitzky <m...@gentoo.org> wrote: > On 06/06/2016 06:04 PM, Tom H wrote: >> 1) I've never used systemd on Gentoo but I assume that you can >> co-install openrc and systemd. So you'd want to check whether systemd >> is running: >> >> [ -d /run/systemd/system ] > > I think the way I did this, it will be a no-op if systemd is not running > (or if e.g. spamd is not running *under* systemd). I committed the cron > job yesterday, so I'll hear about it if it doesn't work. I've just looked at your script. Do systemctl try-restart spamassassin and systemctl try-restart amavisd need "2>/dev/null" if you're booted with sysvinit+openrc but have systemd installed like the rc-service invocations in the opposite case? or do they fail silently? >> 2) spamassassin.service is running >> 3) reload or restart spamassassin.service >> >> systemctl try-reload-or-restart spamassassin.service >> if sa is running, it'll reload it if sa supports a reload, otherwise >> it'll restart it > > Ah, that sounds like an improvement. It looks like amavisd.service > supports reloading, but spamd.service doesn't. The way we do it in > spamd.init is to send a HUP signal to the spamd process (determined from > its PID file). Google tells me that > > ExecReload=/bin/kill -HUP $MAINPID > > should work... It's the canonical way.
Re: [gentoo-user] Re: Change from udev to eudev?
On Monday, June 13, 2016 02:10:27 PM James wrote: > wabe gmail.com> writes: > Still, if you manage 1000 linux workstations, then systemd does have > it's merits. Serious question: What makes systemd more suitable to manage 1000 linux workstations when compared to, for instance, OpenRC? -- Joost
Re: [gentoo-user] Re: udev -> eudev
2016-02-09 11:28 GMT-06:00 Jc García <jyo.gar...@gmail.com>: > 2016-02-09 11:21 GMT-06:00 James <wirel...@tampabay.rr.com>: > >> >> # grep -r systemd /etc/portage > ... >> /etc/portage/package.use/zzz-autounmask:>=sys-fs/udisks-2.1.4 systemd > > look at that file and that line why that was activated. and delete it, and change the useflags for the package that might have caused it if any.
Re: [gentoo-user] Re: udev -> eudev
2016-02-09 11:21 GMT-06:00 James <wirel...@tampabay.rr.com>: > > # grep -r systemd /etc/portage ... > /etc/portage/package.use/zzz-autounmask:>=sys-fs/udisks-2.1.4 systemd look at that file and that line why that was activated.
[gentoo-user] Systemd good or bad?
I read in the history feeds that the universal init system (formerly known as systemd) was controversial when introduced. I would like the opinions of people from your time. -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com
Re: [gentoo-user] Portage spokes again...
161221 Walter Dnes wrote:
> On Wed, Dec 21, 2016 at 05:25:20AM +0100, meino.cra...@gmx.de wrote
>> sys-apps/systemd:0= required by (sys-apps/dbus-1.10.12:0/0::gentoo, ebuild
>> scheduled for merge)
>> I have no systemd installed...my Linux is running good ole openrc...
>> Why all these systemd blockers?
> I wonder if systemd is a default USE flag for a package somewhere.
> Try adding " -systemd " to USE in make.conf to explicitly disable it,
> and re-run the emerge.
'dbus' has a 'systemd' USE flag, wh looks as if it's the default :
root:501 ~> eix ^dbus$
[I] sys-apps/dbus
Available versions: 1.8.16 ~1.8.22 1.10.8-r1^t 1.10.12^t ~1.10.14^t {X
debug doc selinux static-libs systemd test user-session ABI_MIPS="n32 n64 o32"
ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
Installed versions: 1.10.12^t([2016-10-23 05:47:09])(X -debug -doc -selinux
-static-libs -systemd -test -user-session ABI_MIPS="-n32 -n64 -o32"
ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
I have '-*' in make.conf , so I'm protected (smile).
--
,,
SUPPORT ___//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Portage spokes again...
Corbin Bird wrote: > > The "sys-fs/eudev" package is the Gentoo fork of "sys-fs/udev" for > people who don't want systemd. Ehm... I still use "sys-fs/udev" (not eudev) without systemd. No problems so far. Do I have to worry? -Matt
Re: [gentoo-user] Portage spokes again...
On Wed, Dec 21, 2016 at 8:53 AM, Corbin Bird <corbinb...@charter.net> wrote: > > ( PulseAudio is also being merged into systemd. Think about it. ) Unless the systemd developers have decided to stop targeting the non-desktop use-case, this is pure delirium.
Re: [gentoo-user] network interface names in gentoo
On 17-06-11 at 16:33, Ian Zimmerman wrote:
> Without tweaking anything in particular (as far as I remember), I get
> the "predictable" names. For example, on the desktop box where I'm
> writing this, the main interface is enp3s0.
>
> But, of course, there's no systemd on this box, and never has been. So,
> reading [1], I am somewhat puzzled: that page sure makes it sound as if
> systemd was responsible for the new style names. What is the mechanism
> by which they appear on gentoo, if not systemd?
Quoting from the sys-fs/eudev-3.2.2-r1 ebuild:
pkg_pretend() {
ewarn
ewarn "As of 2013-01-29, ${P} provides the new interface renaming
functionality,"
ewarn "as described in the URL below:"
ewarn
"https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames;
ewarn
ewarn "This functionality is enabled BY DEFAULT because eudev has no
means of synchronizing"
ewarn "between the default or user-modified choice of sys-fs/udev. If
you wish to disable"
ewarn "this new iface naming, please be sure that
/etc/udev/rules.d/80-net-name-slot.rules"
ewarn "exists: touch /etc/udev/rules.d/80-net-name-slot.rules"
ewarn
}
and from sys-fs/udev-233:
elog
elog "Starting from version >= 197 the new predictable network
interface names are"
elog "used by default, see:"
elog
"https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames;
elog
"https://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c;
elog
elog "Example command to get the information for the new interface name
before booting"
elog "(replace with, for example, eth0):"
elog "# udevadm test-builtin net_id /sys/class/net/ 2>
/dev/null"
elog
elog "You can use either kernel parameter \"net.ifnames=0\", create
empty"
elog "file /etc/systemd/network/99-default.link, or symlink it to
/dev/null"
elog "to disable the feature."
Depending on which of those you have installed.
--
Simon Thelen
[gentoo-user] Re: Why I can't I build systemd without ipv6?
On 2017-10-13, Daniel Frey <djqf...@gmail.com> wrote: > And is there a way to build systemd without ipv6? Or am I going to have > to revert these three systems back to openrc? ^^ You misspelled "upgrade". ;) -- Grant Edwards grant.b.edwardsYow! I am NOT a nut at gmail.com
[gentoo-user] Systemd
Hello, I have a short question to systemd. I would like to ask your experience in the changeover. Was it easy? Were there problems? Change or reinstall? What mean the profis here? Thank you for help and have nice weekend. Silvio pgpPdmay_r_Vp.pgp Description: PGP signature
[gentoo-user] start ntpdate after network....
Hi people, I have my gentoo system running with systemd. I figured out that ntpdate is getting started before network is up. I am not yet very familiar with systemd. Can somebody of you tell me how to fix that, that "ntpdate" is started the moment network devices are up ? for any response and ideas, thank you! best, Tamer
[gentoo-user] Re: switch from gnome/systemd to xfce/openrc borked my system - I GIVE UP
On 2019-08-20, Raffaele Belardi wrote: > Raffaele Belardi wrote: [...] > - I grub-loaded a different kernel, one built for systemd. It stops in > the exact same place as the openrc-built one. What are the kernel command lines for both kernels? -- Nuno Silva
Re: [gentoo-user] systemd crashes when I try to mount a USB drive
On 2019.08.01 09:59, Helmut Jarausch wrote: Hi, since the upgrade from systemd-242-r6 to systemd-243_rc1 I cannot mount my (external) USB drive any more. I get kernel: sd 10:0:0:0: [sde] Assuming drive cache: write through kernel: sde: sde1 sde2 sde3 sde4 sde5 sde6 sde7 kernel: systemd-udevd[480887]: Assertion 'key' failed at src/libsystemd/sd-device/device-private.c:34, function device_add_property(). Aborting. The strange thing is, I don't use systemd on start-up (I'm using openrc) but I have systemd installed here. This configuration has been working for a very long time. Many thanks for a hint, Helmut Helmut, You say you don't use systemd on start-up, but is any of it running when you get this error? If you aren't using it at start-up, I wonder what the implcations are of having it installed - where might it have insinuated itself, so it gets called instead of something else you might have expected. Next time you get the error, can you do "ps auxf" to see if you can tell what processes called systemd-udevd? Jack
[gentoo-user] custom mount fstab
Hi people, I had a problem with docker on gentoo and found the solution for all my problems with a custom mount command: |sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd Can anybody of you tell me how to add that one in /etc/fstab file ? best, Tamer |
[gentoo-user] Re: Switching default tmpfiles and faster internet coming my way.
Michael wrote: > > Given M.Orlitzky's comments and discussions with systemd devs he shared, > what's the optimal solution for OpenRC users, who want to avoid systemd? Simply stay with opentmpfiles. > Rely on ebuild creators and maintainer checks to guard against these inherent > vulnerabilities? Rely on ebuild creators to not write into world-writable directories during emerge. This should never happen in the first place.
[gentoo-user] openrc install possible systemd too complex
This was even following the steps in that systemd gentoo wiki article. I'm glad I tried it since if I hadn't I'd never know. -- United States has 633 Billionaires with only 10 doing any annual significant giving.
Re: [gentoo-user] network do not come up after booting, only manual reloading (systemd-networkd)
On 06/09/2021 20:45, Tamer Higazi wrote: Dear Dr. Valdés, /etc/systemd/network/20-wirded.network: ^ Typo? Unimportant? Significant? Cheers, Wol
Re: [gentoo-user] A couple of problems with systemd
On Fri, 27 May 2022 17:49:24 -0400, Neil Bothwick wrote: > > [1 ] > On Fri, 27 May 2022 17:03:29 -0400, John Covici wrote: > > > I have one service which always times out, but slows down the boot > > process. It is > > /lib/systemd/system/systemd-networkd-wait-online.service. Because > > many jobs wait in queue for a while, till this fails. > > Are you using systemd-networkd or something else to manage your network? > > > Also, I have a couple of services, ntpdate and proftpd which always > > fail because when they try to execute named has not started yet. I > > can restart them once the system is fully booted and I can login. > > You can create a drop-in to require the service to start after named, run > "systemctl edit ntpdate.service" and add > > [Unit] > Requires=named.service > After=named.service > > That will create a drop-in file in /etc/systemd/system/ntpdate.service.d > containing your additions - you can also create these files manually. Thanks. I am not usingsystemd-network or anything like that.I created a service called network and use the %i and links in /etc/systemd/system/multi-user-target.wants to start my two cards. Maybe this is not the normal way, but when I first started using systemd, this is the best I could come up with at the time. I will try the drop-in, I had kind of forgot about them. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
[gentoo-user] systemd-boot on openrc
Hello list, I've been using bootctl from sys-boot/systemd-boot for several years, with some success, but I'm stuck after today's --sync. First I was told I had to keyword sys-apps/systemd-utils, so I did that, but now I get this, which I can't decode: Calculating dependencies ... . . done! [ebuild N~] sys-apps/systemd-utils-250.4::gentoo USE="boot (split-usr) sysusers tmpfiles udev (-selinux) -test" ABI_X86="(64) -32 (-x32)" 10,872 KiB [ebuild U ~] sys-boot/systemd-boot-250::gentoo [249.9::gentoo] 0 KiB [blocks b ] =sys-fs/ udev-232:0/0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (>=sys-fs/udev-232:0/0[abi_x86_64(-)]) required by (virtual/libudev-232- r5-2:0/1::gentoo, installed) USE="-systemd" ABI_X86="(64) -32 (-x32)" >=sys-fs/udev-217 required by (virtual/udev-217-r3-1:0/0::gentoo, installed) USE="" ABI_X86="(64)" This is an amd64 openrc system. On another system, ~amd64 openrc, I was told to set USE=boot on systemd-utils, so I did that and now when I boot I have no mouse or keyboard. Is this the end of the road for systemd-boot on openrc? -- Regards, Peter.
[gentoo-user] Re: systemd-boot on an openrc system
On 28/09/2022 15:20, Peter Humphrey wrote: Looking more carefully, I see only one machine has an /etc/machine-info. I'm on systemd (openrc is not installed at all), and I don't have /etc/machine-info. And /etc/kernel/install.d/ is empty.
Re: [gentoo-user] NetworkManager problem after migrating to systemd
2012/10/30 Canek Peláez Valdés can...@gmail.com On Tue, Oct 30, 2012 at 3:45 PM, João Matos jaon...@gmail.com wrote: 2012/10/29 Canek Peláez Valdés can...@gmail.com On Mon, Oct 29, 2012 at 4:42 PM, João Matos jaon...@gmail.com wrote: I found the solution a few hours ago here http://en.gentoo-wiki.com/wiki/Systemd#PAM_support:_su.2C_sudo.2C_screen. .. . Now everything is fine :) About the packages you mentioned, you've ran 'equery uses pambase polkit udisks upower', and none of them has the userflag systemd. # equery uses pambase polkit udisks upower [: I - package is installed with flag ] * Found these USE flags for sys-auth/pambase-20120417-r1: [snip] + + systemd : Use pam_systemd module to register user sessions in the systemd control group hierarchy. * Found these USE flags for sys-auth/polkit-0.107-r1: [snip] + + systemd : Use sys-apps/systemd instead of sys-auth/consolekit for session tracking * Found these USE flags for sys-fs/udisks-2.0.0: [snip] + + systemd : Support sys-apps/systemd's logind * Found these USE flags for sys-power/upower-0.9.18: [snip] + + systemd : Use sys-apps/systemd for hibernate and suspend Depends on the versions ;) yep. I've used ~amd64 for about 5 years, but last year I decided to use amd64. Maybe systemd suport is better in more recent packages. Indeed it is. I don't run ~amd64, BTW; I just keyword some things (the kernel, systemd+udev, and GNOME, basically). Well, I've just find out a new little problem: PulseAudio. I've found nothing about systemd+pulseaudio on google, what means that it is too easy to some one carry about writing about it, or nobody tried it yet. Does anyone knows how to start it? Maybe writing a pulseaudio.service or something like that. Both projects have the same author: Lennart Poettering. There is usually nothing to be done so they work together; in GNOME, PulseAudio is started automatically by the session manager, I suppose it should be something similar in KDE-land. Actually, since PA is a user (not a system) service, the init system you use doesn't matter. The past week I've changed my whole system (get rid of genkernel, installed systemd...). It's been difficult to find out how to solve some problem that appear, because I have to guess what originated it. But I think I have a progress with that one: revdep-rebuild found a problem with pulseaudio (and some others), I still get an error while I compile it, but I'm working on it. I was thinking It should be a service, since it was on my rc default level. But it seems it is not encouraged anymore. Thank you anyway. -- João de Matos Linux User #461527
Re: [gentoo-user] NetworkManager problem after migrating to systemd
On Tue, Oct 30, 2012 at 4:49 PM, João Matos jaon...@gmail.com wrote: 2012/10/30 Canek Peláez Valdés can...@gmail.com On Tue, Oct 30, 2012 at 3:45 PM, João Matos jaon...@gmail.com wrote: 2012/10/29 Canek Peláez Valdés can...@gmail.com On Mon, Oct 29, 2012 at 4:42 PM, João Matos jaon...@gmail.com wrote: I found the solution a few hours ago here http://en.gentoo-wiki.com/wiki/Systemd#PAM_support:_su.2C_sudo.2C_screen... . Now everything is fine :) About the packages you mentioned, you've ran 'equery uses pambase polkit udisks upower', and none of them has the userflag systemd. # equery uses pambase polkit udisks upower [: I - package is installed with flag ] * Found these USE flags for sys-auth/pambase-20120417-r1: [snip] + + systemd : Use pam_systemd module to register user sessions in the systemd control group hierarchy. * Found these USE flags for sys-auth/polkit-0.107-r1: [snip] + + systemd : Use sys-apps/systemd instead of sys-auth/consolekit for session tracking * Found these USE flags for sys-fs/udisks-2.0.0: [snip] + + systemd : Support sys-apps/systemd's logind * Found these USE flags for sys-power/upower-0.9.18: [snip] + + systemd : Use sys-apps/systemd for hibernate and suspend Depends on the versions ;) yep. I've used ~amd64 for about 5 years, but last year I decided to use amd64. Maybe systemd suport is better in more recent packages. Indeed it is. I don't run ~amd64, BTW; I just keyword some things (the kernel, systemd+udev, and GNOME, basically). Well, I've just find out a new little problem: PulseAudio. I've found nothing about systemd+pulseaudio on google, what means that it is too easy to some one carry about writing about it, or nobody tried it yet. Does anyone knows how to start it? Maybe writing a pulseaudio.service or something like that. Both projects have the same author: Lennart Poettering. There is usually nothing to be done so they work together; in GNOME, PulseAudio is started automatically by the session manager, I suppose it should be something similar in KDE-land. Actually, since PA is a user (not a system) service, the init system you use doesn't matter. The past week I've changed my whole system (get rid of genkernel, installed systemd...). It's been difficult to find out how to solve some problem that appear, because I have to guess what originated it. But I think I have a progress with that one: revdep-rebuild found a problem with pulseaudio (and some others), I still get an error while I compile it, but I'm working on it. I was thinking It should be a service, since it was on my rc default level. But it seems it is not encouraged anymore. Thank you anyway. System wide mode was introduced in 0.9.3 six years ago. Since then it hasn't been recommended for normal usage, just for some embedded systems and other situations where the notion of user doesn't make sense: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Questions about systemd logging
On Wed, Jan 9, 2013 at 5:12 AM, Robin Atwood robin.atw...@attglobal.net wrote: I have temporarily shelved my problem with mounting since my work-around seems adequate. But I have some questions about logging. Journald works fine but what am I supposed to see on the main console? What do you mean by main console? tty1? tty12? /dev/console? All I can see is a few kernel messages which cease after the lvm service completes. There are no service starting messages and no login prompt appears. The other ttys have a banner and prompt as usual. systemd by default only spawns 1 (one) tty, tty1: $ ls /etc/systemd/system/getty.target.wants/ getty@tty1.service That's the only login prompt spawned by default. The other virtual consoles get spawned automatically if you switch to them. In other words, if you never switch to the virtual console 2, there is no login prompt there. It will appear until you switch to it. systemd should switch to tty1 and launch getty@tty1.service automatically when the getty.target is reached in the boot process. I'm not really sure what the problem is; if you are concerned by the [ OK ] messages when booting, it is possible that systemd is so fast that you have no chance to see them (that happens in my laptop with a solid state harddrive). Also, if you have a splash (like plymouth), the whole point of the splash is that you don't see said messages. You can see a copy of the boot log in /var/log/boot.log; that it's what you are supposed to see when booting, but if you have a splash you won't, or maybe it will be so fast that you will miss it. Secondly I want to merge the journal into syslog-ng for post-processing. I have the correct syslog-ng service defined and syslog-ng.conf has been modified to use /run/systemd/journald/syslog as a source unix-stream. But I see no systemd messages appearing. In the Gentoo package all the journald.conf statements are commented out, which ones are necessary to do what I want. I have tried the logging_to_syslog/kmsg options but to no effect, but there are many! I switched from syslog-ng to rsyslog around three years ago, and exclusively to the journal some months ago, so this is from memory: 1. You need to link your syslog service unit to /etc/systemd/system/syslog.service; for example: /etc/systemd/system/syslog.service - /usr/lib/systemd/system/syslog-ng.service 2. You need to set LogTarget=syslog (or LogTarget=syslog-or-kmsg) in /etc/systemd/system.conf. You are configuring *systemd* to use a third party syslog; you don't need to configure the journal itself. man 5 systemd.conf man 1 systemd If I recall correctly, that's it. systemd automatically will buffer the early boot messages until your preferred syslog service start, and from that point on it will send the logs to it immediately. Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] systemd-197-r1 starts gdm-3.6.2
On Wed, Jan 30, 2013 at 11:48 AM, Stefan G. Weichinger li...@xunil.at wrote:
Am 30.01.2013 18:36, schrieb Hinnerk van Bruinehsen:
I've just installed systemd on one of my systems to give it a test and I
had similar problems due to the systemd useflag on policykit being
hardmasked (it also pulled in consolekit because of that).
Since the errors are very similar you may check your useflags on
policykit and - if necessary remove the use-mask of systemd for
policykit.
As Hinnerk said, it could be a PolKit problem, but you said that you
had unmasked the systemd USE flag from PolKit. The new information I
see in this mail is that you have =gnome-base/gnome-session-
installed; why do you have a live version? Did you use --autounmask to
install GNOME?
I think that's the problem: gnome-session has no live version in the
tree; therefore you are installing it from the GNOME overlay. The live
version of gnome-session in the GNOME overlay doesn't use a specific
version, tag or branch to checkout, so depending on when you installed
it, it's possible you are running gnome-session-3.7.x.
I would keep gnome-session keyworded, but unmasked; that would force
the install of the 3.6.2 version. Also, if you have more live
versions, I would recommend downgrading them to the last 3.6.x
version. GNOME 3.6 is not masked in Gentoo, just keyworded.
Let me get that straight:
I have:
# cat profile/package.use.mask
media-sound/pulseaudio -systemd
net-misc/networkmanager -systemd
sys-auth/polkit -systemd
sys-fs/udisks -systemd
sys-power/upower-systemd
because of some older thread or the gentoo wiki for systemd (can't
remember right now).
This gets me:
[I] sys-auth/polkit
Available versions: 0.107-r1 0.110 {examples gtk +introspection
kde nls pam selinux systemd}
Installed versions: 0.110(18:09:30 30.01.2013)(gtk introspection
nls pam systemd -examples -kde -selinux)
while I have USE= ... -consolekit systemd ... in make.conf.
I also get consolekit installed here:
[I] sys-auth/consolekit
Available versions: 0.4.5_p20120320-r1 {acl debug doc pam
policykit selinux test KERNEL=linux}
Installed versions: 0.4.5_p20120320-r1(18:13:50 30.01.2013)(acl
pam policykit -debug -doc -selinux -test KERNEL=linux)
What exactly do you suggest now?
If you have -consolekit, why it's still installed? What is pulling it
into your system? Can you do a equery depends consolekit?
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] systemd-197-r1 starts gdm-3.6.2
On Wed, Jan 30, 2013 at 11:35 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Jan 30, 2013 at 3:14 PM, Alecks Gates aleck...@gmail.com wrote: On Wed, Jan 30, 2013 at 2:22 PM, Stefan G. Weichinger li...@xunil.at wrote: [snip] I switched to systemd not too long ago and I have the same issue as well, at least it sounds the same -- Basically, I get a hanging GDM after typing my password and logging in. I'm certainly no expert, but I've enjoyed the rest of systemd so I've stuck with it and just use startx to boot into Gnome3. I'll attatch some logs from /var/log/gdm. Alecks, your error is different, and one similar to one I had before: https://bugs.gentoo.org/show_bug.cgi?id=363061 What does systemctl status accounts-daemon.service says? Actually, could tell me what services are in red when you run systemctl --full --all? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México $ systemctl status accounts-daemon.service accounts-daemon.service - Accounts Service Loaded: loaded (/usr/lib64/systemd/system/accounts-daemon.service; disabled) Active: active (running) since Thu 2013-01-31 17:02:33 CST; 16min ago Main PID: 3326 (accounts-daemon) CGroup: name=systemd:/system/accounts-daemon.service └─3326 /usr/libexec/accounts-daemon $ systemctl --full --all | grep error auditd.service error inactive dead auditd.service plymouth-quit-wait.service error inactive dead plymouth-quit-wait.service plymouth-start.service error inactive dead plymouth-start.service syslog.service error inactive dead syslog.service A couple days ago (after reading your email from another topic) I noticed plymouth services do not exist on my machine, and checked where it's supposed to come from: $ e-file plymouth-start.service [I] sys-apps/systemd Available Versions: 44-r1 44 Last Installed Ver: 197-r1(Mon 28 Jan 2013 03:58:41 PM CST) Homepage: http://www.freedesktop.org/wiki/Software/systemd Description:System and service manager for Linux Matched Files: /usr/lib/systemd/system/sysinit.target.wants/plymouth-start.service; /usr/lib/systemd/system/plymouth-start.service; $ e-file plymouth-quit-wait.service [I] sys-apps/systemd Available Versions: 44 44-r1 Last Installed Ver: 197-r1(Mon 28 Jan 2013 03:58:41 PM CST) Homepage: http://www.freedesktop.org/wiki/Software/systemd Description:System and service manager for Linux Matched Files: /usr/lib/systemd/system/multi-user.target.wants/plymouth-quit-wait.service; /usr/lib/systemd/system/plymouth-quit-wait.service; And auditd.service isn't found in e-file at all. Normally I'm not surprised by a lack of .service files, as it's not a huge issue[1], but if this one's so important, where is it? Canek, I'm getting the feeling your systemd install has matured over the years, at least with regard to unit files. [1] Unit files are surprisingly easy for me to create -- I always found a barrier to entry with init scripts. Alecks
Re: [gentoo-user] gentoo-systemd-only deprecation
On Wed, Jul 31, 2013 at 10:26 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-07-31 11:20 AM, Canek Peláez Valdés can...@gmail.com wrote: If you don't use the systemd USE flag (and never install anything that depends on systemd), you will not get systemd installed, but many packages will install systemd unit files in /urs/lib/systemd/system. This unit files are little non-executable files which do nothing in your system, but some people feel really strongly about having anything in their machines with *systemd* in its path. If you want to exorcise those unit files, add /usr/lib/systemd/system to INSTALL_MASK. Ok, thanks Canek... but my last question remains... if this really is going to be the only and one true way to opt out of systemd, shouldn't this be well documented in the man page, as opposed to just generic references to masking 'files'...? No, because the *exact same* situation occurs for Bash completion scripts... and logrotate scripts... and cron jobs... and... The devs decided (and I agree with them) that the important thing is to cover the necessities of the majority of users and to have reasonable default settings. Therefore, having USE flags for bash_complete, and logrotate, and crond, and systemd, and OpenRC, and whatever else you want to throw in the mix is overkill and a maintenance nightmare. Not to mention that they will require a full rebuild every time you changed one of those flags. And the packages (in general) will not care about those tiny files; they will work fine with all of them installed, no matter if you don't use Bash completion, nor logrotate, nor crond, nor systemd nor OpenRC. So, those files are installed unconditionally. And that's the smart thing to do, since most users will not even care about any of them. There is no need to document nothing special about any of them (bash_complete, logrotate, crond, systemd, OpenRC, etc.), since that option is for really special cases (think embedded devices with really small disk space), or for really picky users (like myself some weeks ago, before I reached the conclusion that masking files in /etc/init.d is not worth it). It's the exact same situation with OpenRC: those of us who install systemd don't want nor need the files in /etc/init.d, but they get installed anyway. If we want to exorcise OpenRC init scripts from our systems, we need to add /etc/init.d to INSTALL_MASK. And so *both* should be fully documented in the man page... No, see above. For the record, I now think it's a waste of time trying to stop the installation of tiny files that basically do nothing, either in /usr/lib/systemd/system or in /etc/init.d, but you have the option if you so desire. Ok, and thanks again... Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] gentoo-systemd-only deprecation
Canek Peláez Valdés can...@gmail.com wrote: On Thu, Aug 1, 2013 at 4:43 AM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Jul 31, 2013 at 02:00:23AM -0500, Canek Peláez Valdés wrote On Wed, Jul 31, 2013 at 1:24 AM, Daniel Campbell li...@sporkbox.us wrote: You need an OpenRC use flag to install OpenRC init scripts? That's simply a lie. An apology to Daniel might be in order. I start my USE flag with -*. During a recent install, I found out the hard way that eudev (and udev) do not install their init scripts without the openrc flag. As you can see from the ebuild fragments below, they require the openrc flag to pull in sys-fs/udev-init-scripts From sys-fs/udev/udev-197-r8.ebuild === PDEPEND==virtual/udev-197-r1 hwdb? ( =sys-apps/hwids-20130114[udev] ) openrc? ( =sys-fs/udev-init-scripts-19-r1 ) From sys-fs/eudev/eudev-1_beta4-r1.ebuild = PDEPEND==virtual/udev-180 openrc? ( =sys-fs/udev-init-scripts-18 ) udev/eudev are special cases: the first is systemd with systemd removed at make install time; the second is a fork of systemd with systemd exorcised. The systemd package also uses the openrc USE flag to install OpenRC init scripts; I hope you agree that it is also an special case (systemd, which is a whole init system, provides init scripts for another init system). The package sys-apps/kmod also uses the openrc USE flag to install an init script, which Create[s] [a] list of required static device nodes for the current kernel. I have no idea why this is necessary, but kmod is a dependency of systemd, and the developers of both projects collaborate a lot between them. No other package in the tree uses an openrc USE flag (or at least they don't appear in /usr/portage/profiles/use.local.desc), except for plymouth, and that it's to install a plugin for OpenRC, not to install its OpenRC scripts. So no package in the tree uses an openrc USE flag to install init scripts, except for one somewhat related to systemd, two forks and/or special handling of systemd, and systemd itself. In *ALL* the other packages in the tree, the OpenRC init scripts are installed unconditionally, as the systemd unit files are. And that's how it should be. Lastly, the ebuilds for udev/eudev should work out of the box in a sane configuration. You have been told several times, both by users and developers, that USE=-* is not really supported; you broke your system by using it, you get to keep the pieces. Gentoo is about choice (or so I keep hearing); that doesn't mean it shouldn't strive to have sane defaults that keep the majority happy: http://blogs.gentoo.org/mgorny/2013/07/23/keeping-the-majority-happy/ So, I hope the package maintainers will create or install systemd units and init.d files so we can have the choice and not spend tons of time maintaining the system -- it gets to the point of being rediculous after a while. Systemd sounds nice, but its frustrating because of this. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 02/17/2014 06:17 AM, Tanstaafl wrote: Thanks to all who chimed in... On 2014-02-16 3:27 PM, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote: [snip] You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. I had read that blog entry before. Is full of errors, like believing that everything that systemd does is inside PID 1. Maybe it is 'full of errors', but is the primary point true? There is actually little code inside PID 1; The quoted text said nothing about this, so please stay on point. As to the point raised: Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. So my main concern is - will it still be possible - *and* easy - in a year? Three years? Five? If the answer to *any* of those is no, then I think the best solution - for gentoo at least - is to make whether or not systemd is to be used more like a *profile* choice - a decision that you can make at install time, similar to choosing between hardened or not (not easy/simple to switch to/from after a system is up and running). In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, having it be a choice made by selecting a corresponding *profile* is the *ideal* solution - at least for gentoo. At least this way everything could be documented, and switching between a systemd and non-systemd profile can be supported for as long as possible, understanding that at some point in time it may have to become an install time choice - kind of like choosing between hardened or not is mostly an install time choice now. That's actually a really smart idea. It would allow for the integration that systemd-fans desire and still respect the choice of people that don't want systemd on their systems. Combined with USE flags and the PORTDIR_MASK variable (iirc), it should create a best of both worlds situation for Gentoo and a decision wouldn't need to be made. Despite my distaste for systemd, I think this is a great middle ground that everyone could, with some considerations or compromises, agree to.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Fri, 21 Feb 2014 16:40:46 -0600 Canek Peláez Valdés wrote: Of course the larger a project is the *potential* number of bugs increases, but so what? With enough developers, users and testers, all bugs are *potentially* squashed. Agreed, but I know of enough large projects with large development teams and even more users that don't get the most basic bugs fixed. Quantity is not equivalent to Quality. I also agree with that. My point is that the systemd project has enough numbers of *talented* developers to do it. You can disagree, of course. Talented developer, maybe. But not talented designers. That's subjective. For me (and many others), the design of systemd is sound. Thanks to your explanation of socket activation it is subjective no longer. Systemd design flaws may be discussed in sheer technical terms, see below. If I were to have sockets created in advance (does it work with TCP/IP sockets?) I would get timeouts on the responses which would lead to some services not starting correctly and ending up in limbo... You don't know how the socket activation works, do you? At boot time, if a service ask for a socket on port 1234 (and yes, they work on TCP/IP sockets), systemd opens the socket for the service, and the service *does not start yet*. When the *first* connection gets into the socket, systemd starts the service, and when it finishes starting, systemd passes the opened socket to it as an fd. Done, now the service has control of the socket, and it will until the services terminates; not when the connection closes (although you can configure it that way), when the *service* terminates. If several connections arrive to the socket *before* the service finishes starting up, the kernel automatically queues them, and when systemd handles the socket to the service, the service does it things for all of them. There is *no single* connection lost. Well, if a godzillion connections arrive before the service finishes starting up, the kernel queue is finite and some would be lost, but it would have to be a lot of connections arriving in a window of some microseconds. And here we have a design issue. I already pointed this issue in this discussion: http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg144144.html Though it was completely ignored by you. I understand: it is easier to discuss design in terms of taste than in technical merits. Systemd assumes that time required to start service is small (at microseconds scale). While this is true for widely used simple setups, this is not true in general case. Service may take seconds or even minutes to start up (good example are services depending on enterprise SAN or large databases). And because systemd never assumes it can take long time to start we have the following issues possible in general case: 1. Client connections are lost due to timeout when service takes long time to start. Systemd fakes service to be available while it isn't still. Thus systemd is not an option for production grade servers. 2. Even if connection timeout is not reached, requests may pale up and be lost. Loss trigger depends on memory available, thus systemd is not an option for both embedded setups and production server setups. As one can see, while systemd socket activation design will work for many case, it will fail for corner ones and by no means can't be used in production (where this corner cases have a high chance to rise). Best regards, Andrew Savchenko pgphWTsbn3Qsg.pgp Description: PGP signature
Re: [gentoo-user] Systemd upower
On 06/03/2014 07:24 PM, Jim Burwell wrote:
FWIW, on my system, I had to mask sys-apps/gentoo-systemd-integration
for it to merge the udev update w/o trying to pull in systemd, et al. i
didn't deep dive on what was trying to pull that in, but masking it
(plus a ton of other stuff I have masked) prevented portage from trying
to build a systemd based system.
OK - I have followed the advice given in eselect news read; I have
also followed the advice on this and the related thread today and
uninstalled sys-power/upower and installed
sys-power/upower-pm-utils. That didn't work. Then, given the above,
I have masked (first) sys-apps/gentoo-systemd-integration and when
that had no effect, masked sys-apps/systemd.
I am still hard-blocked out of updating:
Calculating dependencies... done!
[ebuild N ] sys-libs/libseccomp-2.1.1 USE=-static-libs 111 kB
[ebuild r U ] app-text/qpdf-5.1.1:0/13 [4.1.0:0/10] USE=-doc
-examples -static-libs {-test} 7,484 kB
[ebuild R] dev-libs/glib-2.38.2-r1:2 USE=mime%* -debug (-fam)
(-selinux) -static-libs -systemtap {-test} -utils -xattr ABI_X86=(64)
(-32) (-x32) PYTHON_TARGETS=python2_7 (-python2_6) 0 kB
[ebuild R ~] x11-libs/libmatewnck-1.6.1:1::mate-overlay
[1.6.1:0::gentoo] USE=introspection startup-notification (-X%*) 0 kB
[ebuild rR] net-print/cups-filters-1.0.53 USE=dbus foomatic jpeg
-perl -png -static-libs -tiff -zeroconf 0 kB
[ebuild U ] net-print/foomatic-db-4.0.20140105 [4.0.20120831] 37,935 kB
[ebuild N#] sys-apps/systemd-212-r5:0/2 USE=acl filecaps
firmware-loader kmod pam policykit seccomp -audit -cryptsetup -doc
-gcrypt -gudev -http -introspection (-kdbus) -lzma -python -qrcode
(-selinux) (-ssl) {-test} -vanilla -xattr ABI_X86=(64) (-32) (-x32)
PYTHON_SINGLE_TARGET=python2_7 -python3_2 -python3_3
PYTHON_TARGETS=python2_7 python3_3 -python3_2 0 kB
[ebuild N#] sys-apps/gentoo-systemd-integration-4 52 kB
[ebuild N ] virtual/libudev-208:0/1 USE=-static-libs
ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild U ] virtual/udev-208-r2 [208-r1] USE=gudev -introspection
-static-libs (-kmod%*) (-selinux%) ABI_X86=(64) (-32) (-x32) 0 kB
[ebuild N ] sys-power/upower-0.9.23-r3 USE=introspection -doc
-ios 0 kB
[uninstall ] sys-power/upower-pm-utils-0.9.23 USE=introspection
-doc -ios
[blocks b ] sys-power/upower (sys-power/upower is blocking
sys-power/upower-pm-utils-0.9.23)
[blocks B ] sys-apps/systemd (sys-apps/systemd is blocking
sys-fs/udev-212-r1)
[blocks B ] sys-apps/gentoo-systemd-integration
(sys-apps/gentoo-systemd-integration is blocking sys-fs/udev-212-r1)
[blocks B ] sys-fs/udev (sys-fs/udev is blocking
sys-apps/systemd-212-r5, sys-apps/gentoo-systemd-integration-4)
Total: 11 packages (3 upgrades, 5 new, 3 reinstalls, 1 uninstall), Size
of downloads: 45,580 kB
Conflict: 4 blocks (3 unsatisfied)
I'm not sure what else to mask/uninstall/reinstall at this point. Any
suggestions?
Re: [gentoo-user] sys-power/upower with systemd
On Tue, Jun 24 2014, Marc Joliet wrote: Am Mon, 23 Jun 2014 20:39:13 -0400 schrieb gottl...@nyu.edu: I think I had first misinterpreted the news msg, but want to be sure I do understand it correctly now. The message ends with All non-systemd users are recommended to choose between: # emerge --oneshot --noreplace 'sys-power/upower-pm-utils' or # emerge --oneshot --noreplace '=sys-power/upower-0.99.0' However, all systemd users are recommended to stay with sys-power/upower. I first read stay with sys-power/upower to mean systemd users should NOT do any of the two options for non-systemd users and let portage do its thing. However, portage want to replace upower with upower-pm-utils, which I am pretty sure is not intended for systemd users. Is the proper reading of the news message, that the systemd users should use the second option available for non-systemd users? Specifically am I to execute # emerge --oneshot --noreplace '=sys-power/upower-0.99.0' ? Um, personally, I think the message is extremely clear: non-systemd users should choose between the first two options, and systemd users should just stick with plain upower, regardless of version (although there is only one ATM, the older one is masked now). I am embarrassed to say that I am still having trouble with this upower business. My profile is .../gnome/systemd and I have the init=/usr/lib/systemd/systemd line GRUB_CMDLINE_LINUX so I am using systemd. right now I have sys-power/upower-0.9.23-r3 installed (the only version below 0.99) and sys-power/upower-pm-utils NOT installed. If I try to update world (see below), portage wants to install sys-power/upower-pm-utils and uninstall sys-power/upower. The output (below) suggests that gnome-shell requires this, but I read the gnome-shell ebuild as permitting my current sys-power/upower-0.9.23-r3 as an alternative. If I try to # emerge --oneshot --noreplace '=sys-power/upower-0.99.0' I get a conflict since several gnome packages (e.g. gnome-shell) explicitly want upower-0.99 Am I supposed to package-mask sys-power/upower-pm-utils? The results shown are on a stable amd64 system (my previous msg concerned another system that I am slowly converting from testing to stable, but this msg only involves a fully stable system). thanks in advance, allan allan ~ # emerge --keep-going --update --changed-use @world These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild U ] x11-wm/sawfish-1.9.1-r2 [1.9.1-r1] USE=emacs%* nls -xinerama 2,556 kB [nomerge ] gnome-base/gnome-3.10.0:2.0 USE=bluetooth cdr classic cups extras -accessibility [nomerge ] gnome-base/gnome-shell-3.10.4-r2 USE=bluetooth i18n networkmanager (-openrc-force) PYTHON_TARGETS=python2_7 [nomerge ] sys-power/upower-pm-utils-0.9.23-r2 USE=introspection -ios [blocks b ]sys-power/upower (sys-power/upower is blocking sys-power/upower-pm-utils-0.9.23-r2) [uninstall ] sys-power/upower-0.9.23-r3 USE=introspection -doc -ios [ebuild N ] sys-power/upower-pm-utils-0.9.23-r2 USE=introspection -ios 0 kB
Re: [gentoo-user] Re: [OT] Linus Torvalds on systemd
On Sat, Sep 20, 2014 at 11:24 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 18.09.2014 um 01:24 schrieb Mark David Dumlao: On Thu, Sep 18, 2014 at 7:11 AM, James wirel...@tampabay.rr.com wrote: Mark David Dumlao madumlao at gmail.com writes: You're the only one in this thread that's imposing on everyone to produce anything. You're the only one in this thread that SHOULD be producing anything. That's how open source works and that's how it's supposed to work. We're not your unpaid researchers. I'm sorry, Volker pointed out that the pro systemd folks came to gentoo-user, waiving linux's dirty panties around. We ask a few simple questions, now you result to name calling? There is no gentoo-user separate from pro systemd folks. You made that up. pro systemd folks have been part of gentoo user for years and years now, and they've been harassed repeatedly with simple loaded questions based on wrong assumptions for years and years now. and that makes it fine to constantly spread pro-systemd propaganga? Just to be clear, I did prefixed the subject with [OT], and in the first paragraph I clearly stated that this as highly off-topic, and systemd related. You could have easily ignored the post, but your bigotry against systemd made you post your laughable arguments. It was *you* who got into an explicitly marked off-topic thread. So.. according to your logic, it would be fine to subscribe to systemd mailing lists and constantly post why distri X or application Y is the best of all? If you marked it off-topic and was slightly related to systemd (like what distro X or app Y works better with systemd), I don't think nobody would mind. It probably would be mostly ignored, though. And as Mark has already stated, systemd is part of Gentoo (now for several years). Any post related to systemd is slightly related to Gentoo, or at least to the many users using it (this is gentoo-user, remember?) I understand that, like a five year old that doesn't want to hear about something, you would prefer that nobody *ever* posted anything positive about systemd, or GNOME, or PulseAudio, or... man, your bigotry is *HUGE*, it even sounds tiring. Anyway; it's not going to happen: we will continue to post systemd-related topics in gentoo-user if we consider them interesting to at least part of the Gentoo community (which several members, including developers, already said they did). So I suggest you to do exactly like a five year old, cover your ears and sing LA-LA-LA, because we are here to stay. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] systemd
Am 11.10.2011 23:04, schrieb Canek Peláez Valdés: [...] systemctl status ssd-thingies.service If everything went OK, it should have a line like this: Process: 1234 ExecStart=/my/path/to/ssd-thingies (code=exited, status=0/SUCCESS) Regards. Thanks for the explanation! I tried it right now, unfortunately I get: # systemctl status ssd-thingies.service ssd-thingies.service - SSD thingies Loaded: loaded (/etc/systemd/system/ssd-thingies.service) Active: failed since Tue, 11 Oct 2011 23:28:05 +0200; 21s ago Process: 6696 ExecStart=/etc/local.d/stefan.start (code=exited, status=203/EXEC) CGroup: name=systemd:/system/ssd-thingies.service Is it a permission-issue? AFAIK systemd runs w/ root? # cat /etc/systemd/system/ssd-thingies.service [Unit] Description=SSD thingies After=basic.target [Service] Type=oneshot ExecStart=/etc/local.d/stefan.start [Install] WantedBy=multi-user.target # ll /etc/local.d/stefan.start -rwxr-xr-x 1 root root 795 11. Okt 16:47 /etc/local.d/stefan.start --- Thanks, greets, Stefan
[gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd.
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras rea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that it makes a lot of sense (at least to me). Most of systemd features can be implemented in OpenRC (although the speed difference will never be eliminated if OpenRC keeps using shell files). My question is: why bother? systemd is already here, it already works, and it's actually supported in Gentoo. But again, remember that I'm biased: I keep an overlay to run Gentoo systems with only systemd; no OpenRC, no baselayout, no SysV. You guys can try it if you want: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ Usual disclaimer: I take no responsibility if using my overlay results in your systems asploding. That said, I'm using it on all my machines without a hitch. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Mar 18, 2012 8:48 AM, Canek Peláez Valdés can...@gmail.com wrote: On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras rea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that it makes a lot of sense (at least to me). Most of systemd features can be implemented in OpenRC (although the speed difference will never be eliminated if OpenRC keeps using shell files). My question is: why bother? systemd is already here, it already works, and it's actually supported in Gentoo. But again, remember that I'm biased: I keep an overlay to run Gentoo systems with only systemd; no OpenRC, no baselayout, no SysV. You guys can try it if you want: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ Usual disclaimer: I take no responsibility if using my overlay results in your systems asploding. That said, I'm using it on all my machines without a hitch. Regards. Interesting... However, what if the service is complex? For example, I created a gatewall service which, upon boot, initializes : * Routing tables and the RPDB * ipset * iptables while ensuring that upon shutdown, the settings of the above are (optionally) saved. How do I specify such intelligence? Rgds,
