You are not logged in.
WOW!!!!
I am puzzled that nobody mentioned refractasnapshot. What an amazing tool!
I wish I had tried it before I went through all this trouble as described above.
I suppose the next stage would be to make a gui out of manually editing the two .conf files while browsing files/folders to exclude and
clicking on boxes for the options.
I had spend some time studying and practicing building live images and there was always something little I'd forget to do right and then the next time I had to figure it all out from scratch, as my note taking abilities are very poor.
This is making backups of the system a breeze. A good reason to be here alone.
One thing that didn't work was altering the directories for work and snapshot, they were still gone to the default locations. No problem.
The other was the part in the conf about processor use, I left it at 50 as was the default, but it went way up there at their limits and temps
went up as well. This went on while it was squashing the file system into the tiny image. I did run a tasks monitor in bg with low priority even
though it is not advised to run anything. I suspect that such process that run as standalones don't matter.
The refracta team deserves an aplaud! I was also told by someone in the xorisso team that they weren't aware of anyone working on a xorisso related gui. I guess this is not specifically a gui of xorisso but it seems that it is the next best thing.
Not happy, extatic of the possibilities this creates for some of us uncomfortable with code and sequences of commands.
rsyslog is a known problem. Just throwing this here but please search the forum and DNG for other discussions.
https://botbot.me/freenode/devuan/2017- … 009&page=6
Bottom line:
fsmithred wrote:rsyslog is not ready. Use syslog-ng or busybox-syslogd instead
syslog-ng seems to work fine, thank you for the heads-up
To each, his own. I couldn't get away from the default slim background fast enough. Is it the blue one or the red one?
That orangy looking mesh that came with ceres upgrade. It saus Text.4 somewhere on it
Here is a quote of a postgresql related headache with a flood of logs
It will be interesting to see what your logs may look like after some use.
In about 10 days of discussion in another distro there hasn't been a reasonable solution to the problem, other than the original dilemma to switch systemd off.
Hi,
I'm running Debian server hosting Request Tracker with Postgresql as
database back-end. There is also gnupg-agent & dirmngr installed
(because of SMIME/GPG mail support). Systemd logs about starting user
sessions and Postgresql for some reason starts user sessions internally
frequently. This is the result of upgrade from Jessie to Stretch on
syslog size:rt2:/etc/systemd# ll /var/log/syslog-2017* |tail
-rw-r----- 1 root adm 8058 Jun 28 06:25 /var/log/syslog-20170628.gz
-rw-r----- 1 root adm 7967 Jun 29 06:25 /var/log/syslog-20170629.gz
-rw-r----- 1 root adm 2537880 Jun 30 06:25 /var/log/syslog-20170630.gz
-rw-r----- 1 root adm 3111373 Jul 1 06:26 /var/log/syslog-20170701.gz
-rw-r----- 1 root adm 3265502 Jul 2 06:26 /var/log/syslog-20170702.gz
-rw-r----- 1 root adm 3264072 Jul 3 06:26 /var/log/syslog-20170703.gz
-rw-r----- 1 root adm 3241260 Jul 4 06:26 /var/log/syslog-20170704.gz
-rw-r----- 1 root adm 3255989 Jul 5 06:26 /var/log/syslog-20170705.gz
-rw-r----- 1 root adm 3256939 Jul 6 06:26 /var/log/syslog-20170706.gz
-rw-r----- 1 root adm 63687210 Jul 7 06:26 /var/log/syslog-20170707I did upgrade on Jun 30...
The system log was full of
Jul 6 06:26:33 rt2 liblogging-stdlog: [origin software="rsyslogd" swVersion="8.24.0" x-pid="406" x-info
="http://www.rsyslog.com"] rsyslogd was HUPed
Jul 6 06:26:36 rt2 systemd[1]: Created slice User Slice of postgres.
Jul 6 06:26:36 rt2 systemd[1]: Starting User Manager for UID 109...
Jul 6 06:26:36 rt2 systemd[1]: Started Session c146966 of user postgres.
Jul 6 06:26:36 rt2 systemd[1860]: Listening on GnuPG cryptographic agent and passphrase cache (restricte
d).
Jul 6 06:26:36 rt2 systemd[1860]: Listening on GnuPG cryptographic agent (access for web browsers).
Jul 6 06:26:36 rt2 systemd[1860]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jul 6 06:26:36 rt2 systemd[1860]: Listening on GnuPG network certificate management daemon.
Jul 6 06:26:36 rt2 systemd[1860]: Reached target Paths.
Jul 6 06:26:36 rt2 systemd[1860]: Reached target Timers.
Jul 6 06:26:36 rt2 systemd[1860]: Listening on GnuPG cryptographic agent and passphrase cache.
Jul 6 06:26:36 rt2 systemd[1860]: Reached target Sockets.
Jul 6 06:26:36 rt2 systemd[1860]: Reached target Basic System.
Jul 6 06:26:36 rt2 systemd[1860]: Reached target Default.
Jul 6 06:26:36 rt2 systemd[1860]: Startup finished in 11ms.
Jul 6 06:26:36 rt2 systemd[1]: Started User Manager for UID 109.
Jul 6 06:26:36 rt2 systemd[1]: Stopping User Manager for UID 109...
Jul 6 06:26:36 rt2 systemd[1860]: Stopped target Default.
Jul 6 06:26:36 rt2 systemd[1860]: Stopped target Basic System.
Jul 6 06:26:36 rt2 systemd[1860]: Stopped target Sockets.
Jul 6 06:26:36 rt2 systemd[1860]: Closed GnuPG network certificate management daemon.
Jul 6 06:26:36 rt2 systemd[1860]: Closed GnuPG cryptographic agent and passphrase cache.
Jul 6 06:26:36 rt2 systemd[1860]: Closed GnuPG cryptographic agent (access for web browsers).
Jul 6 06:26:36 rt2 systemd[1860]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Jul 6 06:26:36 rt2 systemd[1860]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Jul 6 06:26:36 rt2 systemd[1860]: Reached target Shutdown.
Jul 6 06:26:36 rt2 systemd[1860]: Starting Exit the Session...
Jul 6 06:26:36 rt2 systemd[1860]: Stopped target Paths.
Jul 6 06:26:36 rt2 systemd[1860]: Stopped target Timers.
...19 user sessions per minute :-/.
I found a bug report
https://bugs.debian.org/cgi-bin/bugrepo … bug=850982But after disabling gnupg-agent & dirmngs sockets using:
systemctl --global mask --now dirmngr.socket
systemctl --global mask --now gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socketI got this
Jul 7 12:16:36 rt2 systemd[21005]: gpg-agent-ssh.socket: Cannot add dependency job, ignoring: Unit gpg-agent-ssh.socket is masked.
Jul 7 12:16:36 rt2 systemd[21005]: gpg-agent.socket: Cannot add dependency job, ignoring: Unit gpg-agent.socket is masked.
Jul 7 12:16:36 rt2 systemd[21005]: gpg-agent-extra.socket: Cannot add dependency job, ignoring: Unit gpg-agent-extra.socket is masked.
Jul 7 12:16:36 rt2 systemd[21005]: gpg-agent-browser.socket: Cannot add dependency job, ignoring: Unit gpg-agent-browser.socket is masked.
Jul 7 12:16:36 rt2 systemd[21005]: dirmngr.socket: Cannot add dependency job, ignoring: Unit dirmngr.socket is masked.instead of info about opening/closing sockets :-/
Finally I tried
loginctl enable-linger postgres
Now the only thing rest:
Jul 7 15:42:35 rt2 systemd[1]: Started Session c4504 of user postgres.
Jul 7 15:42:35 rt2 systemd[1]: Started Session c4505 of user postgres.
Jul 7 15:42:35 rt2 systemd[1]: Started Session c4506 of user postgres.
Jul 7 15:42:35 rt2 systemd[1]: Started Session c4507 of user postgres.
Jul 7 15:42:35 rt2 systemd[1]: Started Session c4508 of user postgres.
Jul 7 15:42:36 rt2 systemd[1]: Started Session c4509 of user postgres.Every minute 19 lines of this.
I have Postgresql installed on several machines and every logs to two remote
syslog servers. Why store and transfer over net this cruft.How I should get rid of this session management the right way? (Besides
switching to SysV init)https://access.redhat.com/solutions/1564823
- this seems to me a bit a hackSwitch systemd LogLevel to notice?
(https://www.centos.org/forums/viewtopic.php?t=48785)
- maybe I will miss something in the future?Isn't this a problem of Postgresql the user session opened so
frequently?Regards
--
Zito
But here is a reasonable analysis of the problem
Václav Ovsík:
> How I should get rid of this session management the right way?I have seen this systemd problem myself.
What is happening is that every time something SSHes in as user postgres,
systemd-logind is starting up a per-user instance of systemd along with with a
whole bunch of per-user socket units (and whatever else you have configured all
per-user service managers to start up); and whenever the SSH session finishes,
systemd-logind is dutifully shutting down that per-user instance.There's no way to actually turn the per-user instance off, for accounts that
should *never* have per-user service managers. The best that you can do is
pretty much the opposite and turn it *always on*. You do this by telling
systemd-logind that the postgres user is a "lingering" user. There is a
loginctl command for doing so. Then it will start up the per-user instance of
systemd and leave it running.(You could also remove the user@.service template outright, which removes
per-user service management for *all* user accounts, including those for real
human beings. However, this still results in log noise, as the failed attempts
by systemd-logind to start up user@NNNN services on every SSH login will all be
logged. In the "lingering" case, there is less log noise.)Of course, the postgres account is most definitely an account which should never
have a per-user service manager. So, too, are dedicated accounts for things
like (say) Nagios monitoring.But there's no mechanism for specifying such accounts, or (conversely, and more
usefully given the general ratio of general-purpose use to role accounts) for
specifying the accounts that should have a per-user service manager and saying
that all other accounts should not. So the best that you can do is be very
aware that everything installed and enabled in /usr/lib/systemd/user is going to
have an instance running with the user access of your postgres account, and be
very careful about what you put in there. (The gpg-agent package has already
dumped some GPG stuff there and enabled it, notice.)
This was the straw for me, to bail out while I was ahead of myself.
This complex simplification of an init system is like a bomb waiting to explode. Too many people trying so many different patches for a ship that is about to sink that it will become acceleratingly comlex to audit or manage. In a year or two nobody will be able to figure out why 99% is inside systemd code.
The problem with too many log files is not the size on the disk but the inablility to review anything and locate anything meaningful.
My 2cents, anyway.
Ανάβω έναν φάρο μπας και ξεβράσει καμιά σκούνα στον κόλπο
Σκέφτομαι να συμβάλω στη μετάφραση αλλά λόγω εκτάκτων συνθηκών και προσωρινής αδυναμίας για δέσμευση και συνέπεια, το αναβάλω.
I know, it sounds all Greek to you but if you can't read the subject why did you click?
Ok, while it is slowly dripping down from surgeforce I like to ask if pulse-audio gets a pid 1
If yes between grub and login you can have this as a theme song play https://www.youtube.com/watch?v=sF2ZqlPNuqU
Deadly serious, I am!
My first install run into problems and I did it a second time. Since I was more comfortable with it I may have overlooked it, although I wouldn't have done it consciously. So the answer is I am not sure, but since others don't have the same problem it seems likely. Were there two options or more, and is this the default? I may have interpret it wrong thinking that it would be a single user no root that is always sudo and I wouldn't want this.
Ok, 2 things I found that corrected the situation.
1 (Possible bug-fix) On file /etc/sudoers which we are not allowed to touch, should there be a % sudo instead of plain sudo? It worked for me as that is how it was in D***an (systemd)
2 The file in /etc/sudoers.d/shutdown can be eliminated or a # should go on the first line.
This procedure definetely fixededit in my LXDE amd64
Please review if there is a problem doing this, or if it is really a bug it can be fixed.
I like this, the "admin" is hijacking my topic
On my testbed installation I jumped to ceres and linux4.11 which comes with header files that are not dependencies and did not exist in 3.16 or (maybe?) 4.9.
Slim was still installed before I switched to my trusty lightdm, but the login screen changed. Great background.jpg (look in share --> slim ). I kept it since lightdm is black bkgrnd. Definetely slim has a very slim footprint. The problem was there was no option to select anything other than entering user and password, so the xfce started.
Glancing through the menu the dreaded "services" was on, clicked and it was there. I got a cold chill down my spine, I thought the systemd nightmare was back! Quickly I checked through the tasks and I suppose those "services" are daemons started by the init system.
Phheeeewwww!!!!!!
update-initramfs -u -k all
and then
update-grub
and it all gets fixed magically (thanks to @dev1 for the hint
it is like it is not even running ...
But it takes me so much time to get used to the hot-keys and having an index card with my poor tired eyes is not helping.
I like dark desktops and working in the dark. I have an enlarged white picture I alt-tab maximized for light
I still go for openbox utilizing some lazyman's lxde gadgets
Update
Lightdm and lxde seem to be able to produce much better graphics than what I experienced initially in xfce
I have installed lxde and anything that runs as a gui when clicked (ie synaptic) asks for "user" pw and works.
Anything in a shell (I mostly use lxterminal) that I try with sudo results:
Sorry, user xxxx is not allowed to execute '/usr/bin/lxtask' as root on mabox
Either through the lxde gui for users and groups or checking sudoers list the user is in sudo group and
other admin tasks. Can't figure it out and has never happened in other distros before.
su works well but I'd rather not use root as I like to keep the history of commands as a user.
Xfce is still installed from the installation. Any chance there is a setting in xfce that overpowers
lxde settings?
PS I am running ascii on amd64
# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
I: The initramfs will attempt to resume from /dev/sda9
I: (UUID=8e052cee-0f67-4af6-guud-707b91db2d1b)
I: Set the RESUME variable to override this.
live-boot: core filesystems devices utils udev wget blockdev dns.
dev/sda9 is the swap partition .... I remember seeing this during shutdown...?
Is it sweeping the swap? 4 different systems share the same swap space and the
same home partition. Not a problem ever. Since I have all 4 users being 1000
they all have access to each other's stuff. I did try a single same name 1001 user
but I like the variety of 4 users. Like this is my purple/violet personality ...!!
http://dev1galaxy.org/viewtopic.php?id=771
This where my installation troubles were listed as I found the topic relevant.
I am worried about somesuch, it always gets me.
IOW, it's a mess because of the same UUIDs, and once you change them and run:
# update-initramfs -u -a
or somesuch, and if all UUIDs are set correctly, i.e. update-initramfs runs without errors, it then can, upon reboot, boot fine.
Here is a good article written by a very mature sys-admin and critic of systemd on the analogy of a system with systemd to a bicycle brake system.
http://troubleshooters.com/linux/systemd/bikebrakes.htm
He is also the author for what some believe as the top of the line manual for sys-administrators anywhere.
Needless to say that I still can't understand 90% of it.
I don't what is a bigger problem, not having logs or not been able to stop them. The new non-bug with systemd is that in some occassions it created a log to start a service and to stop it, creating a ton per minute of useless logging.
Thank you @golinux for the recommended alternatives.
@miroR you asked me for a link and I have no idea what link this may be. What I am talking about in reference to cloning is to make an installation in partition sdz1 and making a copy in partition sdy3 and debelop from the same snaposhot of the system 2 different ways.
All you need to do is to "properly" edit fstab with new uuids and the grub.cfg
I suspect, without knowing, that the initrd.img in /boot contains the original uuid which is passed to grub and it creates this confusion.
Once linux kernel gets updated all this goes away. In other words unattended updates of grub creates an entry with two different uuids for the same menu item, which results to a prompt at the initrdmfs prompt where there is not much you can do (or maybe there is if you know how to deal with it).
The only glitch which may be related to the lxde desktop not really being a devuan ported pkg, was rsyslog which in ascii it says it has unmet non-existent dependencies. So I removed it.
Everything else is running fine.
Hopefully this information may help someone else cloning their devuan installation. I do this often when I want to play either with unstable or compile software that may break the system as a testing installation and only apply procedures that work on my main installation.
In this case I reversed the process leaving the original installation as the playground.
Let's see what ceres does (I am really going to miss SID as I liked the name - I will rename my grub entry Devuan SID or Vicious Devuan)
So long, systemd suckers!
As mentioned elsewhere in my installation experience when I cloned the original usb installation to a different partition (dev/sda11) with a new uuid grub although updated and found the clone it had mixed uuid instructions based on the initrd-image found in the boot menu, and kept looking for the old uuid to boot which was not plugged.
Interestingly if the original installation was plugged in (let's say /dev/sdb1), although the grub menu would have two other lines defining sda11 as a specific/correct id it would eventually boot from sdb1.
Correcting grub to match the properly edited fstab for root booted, but it seemed slow and confused.
I am running ascii. I added ceres repositories and only installed linux-4.11 from which I am booted now.
I removed 3.16 and reinstalled 4.9
By the way, with ascii and booting 4.11 I have yet to experience anything strange, it works like a charm.
During the removal and reinstallation I got this:
(Reading database ... 147327 files and directories currently installed.)
Purging configuration files for linux-image-3.16.0-4-amd64 (3.16.43-2+deb8u2) ...
debconf: unable to initialize frontend: Gnome
debconf: (Can't locate Gtk2.pm in @INC (you may need to install the Gtk2 module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Debconf/FrontEnd/Gnome.pm line 91.)
debconf: falling back to frontend: Dialog
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
This may be due to the inconsistency of running ceres kernel in ascii, I will now reboot and revert the kernel to 4.9 and remove 4.11
I will report back on how it went!
SOLVED!!!!!!
I went back for a detailed look at grub, since the error was within the initramfs and the root location could not be located.
menuentry 'Devuan GNU/Linux ascii/ceres (on /dev/sda11)' --class devuan --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-xxxxxx-new--UUID-----xxxxxxxx' {
savedefault
insmod part_msdos
insmod ext2
set root='hd0,msdos11'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos11 --hint-efi=hd0,msdos11 --hint-baremetal=ahci0,msdos11 xxxxxx-new--UUID-----xxxxxxxx
else
search --no-floppy --fs-uuid --set=root xxxxxx-new--UUID-----xxxxxxxx
fi
linux /boot/vmlinuz-4.9.0-3-amd64 root=UUID=xxxxxx----OLD--UUID-----xxxxxxxx ro quiet
initrd /boot/initrd.img-4.9.0-3-amd64
}
Grub although it finds the right UUID from the partition in the part of the entry where the linux image to boot from is it picks up something from within the initrd.img...... which contains the original UUID of the installation.
It boots now, but it is slow, I guess I would have to reinstall the two kernels to fix this (booting one reinstalling the other
Hurray.... now the fun really begins.
Damn dumb Grub, I thought it only screws up on Arch based distros.
See you-all later!
Cleaning up shop in my new devuan installation
I agree with you 100%, I only use UUIDs on fstab
Here the problem is not finding and mounting other partitions, I could live doing it manually, but it is the
root mounting that is absent. The uuid on fstab is correct, the system while it is trying to start gets an
instruction of the uuid of the original installation. It replies uuid not existing, and returns me to intramfs which I don't know how to debug. The root partition never gets reached, so there are no logs there.
There are several reasons why a UUID may need to change in a system, hd replacement, moving the system to another partition, etc. In all other linux distributions I have ever tried all I had to do was edit fstab and update grub. Not on Devuan.
Back to disk labels, the installation was done on sdb1, it was then cloned to sda11, then sda11 received a
new uuid, fstab was edited and grub was updated with sdb1 upnplugged. When sda11 tries to boot it is looking for the uuid of sdb1 not sda11 as the uuid in grub.cfg and fstab indicate.
Where is it at?
I remember specifically in the installation (both times, first failed) I asked that UUIDs are used over labels and dev/sdxx as being more accurate.
The installation came with an fstab that only mounted the device number /dev/sda1 (ie) and partition labels.
I edited the fstab to match uuids. When I got the system where I wanted I logged into a different system, created a new partition and used dd to copy the partition of the installed devuan into the new one. Then as the uuid of the flash drive partition was copied into the hd, I used gparted to check partitions and gave the clone a new uuid and edited the new fstab to match.
Nothing, it will not even find the root of the system (grub found the installed clone and had the correct uuid). I switched between labels and /dev/sdxx no difference.
While playing with that debian module for non-bootable systems I noticed while I tried mount -a that the system is still seeking the UUID of the original installation, so there is some place where this is specified and can be changed, although I don't know where.
Three different linux distributions I had done this before did not have this problem.
But the above post is already 10days old and did not get a response, so I may be waiting and searching for a while.
amd graphics and using intel i915 drivers/firmware? Are am I reading all this wrong?
more i915 problems here, i see.
My installation identifies the monitor as a 22" generic something, when all other distributions I've tried identified it correctly as a 32" Hyundai.
The dpi for a 1920x1024 resolution seem really crappy, like 4 pixels act as one.
the misc-non-free-firmware seemed to solve many problems in i915 graphics, which I see we share.
Maybe we can compile and import here?
I am going to try to do something during the weekend, I am enjoying it now before I break it
Cheer(io)s